7. RoleBinding 示例
下面示例是 RoleBinding 中的片段，仅展示其 subjects 的部分。
对于名称为 alice@example.com 的用户：
subjects: - kind: User name: "alice@example.com" apiGroup: rbac.authorization.k8s.io
对于名称为 frontend-admins 的用户组：
subjects: - kind: Group name: "frontend-admins" apiGroup: rbac.authorization.k8s.io
对于 kube-system 名字空间中的默认服务账号：
subjects: - kind: ServiceAccount name: default namespace: kube-system
对于 “qa” 名字空间中所有的服务账号：
subjects: - kind: Group name: system:serviceaccounts:qa apiGroup: rbac.authorization.k8s.io
对于在任何名字空间中的服务账号：
subjects: - kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io
对于所有已经过认证的用户：
subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io
对于所有未通过认证的用户：
subjects: - kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io
对于所有用户：
subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io - kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io
8. 默认 Roles 和 Role Bindings
API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 这其中许多是以 system: 为前缀的，用以标识对应资源是直接由集群控制面管理的。 所有的默认 ClusterRole 和 ClusterRoleBinding 都有 kubernetes.io/bootstrapping=rbac-defaults 标签。
注意： 在修改名称包含 system: 前缀的 ClusterRole 和 ClusterRoleBinding 时要格外小心。
对这些资源的更改可能导致集群无法继续工作。
9. 面向用户的角色
一些默认的 ClusterRole 不是以前缀 system: 开头的。这些是面向用户的角色。 它们包括超级用户（Super-User）角色（cluster-admin）、 使用 ClusterRoleBinding 在集群范围内完成授权的角色（cluster-status）、 以及使用 RoleBinding 在特定名字空间中授予的角色（admin、edit、view）。
面向用户的 ClusterRole 使用 ClusterRole 聚合以允许管理员在 这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 admin、edit 或者 view， 可以创建带有以下一个或多个标签的 ClusterRole：
metadata: labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rbac.authorization.k8s.io/aggregate-to-view: "true"
10. 核心组件角色
11. 其他组件角色
12. 内置控制器的角色
Kubernetes 控制器管理器 运行内建于 Kubernetes 控制面的控制器。 当使用 --use-service-account-credentials 参数启动时, kube-controller-manager 使用单独的服务账号来启动每个控制器。 每个内置控制器都有相应的、前缀为 system:controller: 的角色。 如果控制管理器启动时未设置 --use-service-account-credentials， 它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。 这些角色包括:
system:controller:attachdetach-controller system:controller:certificate-controller system:controller:clusterrole-aggregation-controller system:controller:cronjob-controller system:controller:daemon-set-controller system:controller:deployment-controller system:controller:disruption-controller system:controller:endpoint-controller system:controller:expand-controller system:controller:generic-garbage-collector system:controller:horizontal-pod-autoscaler system:controller:job-controller system:controller:namespace-controller system:controller:node-controller system:controller:persistent-volume-binder system:controller:pod-garbage-collector system:controller:pv-protection-controller system:controller:pvc-protection-controller system:controller:replicaset-controller system:controller:replication-controller system:controller:resourcequota-controller system:controller:root-ca-cert-publisher system:controller:route-controller system:controller:service-account-controller system:controller:service-controller system:controller:statefulset-controller system:controller:ttl-controller
13. 对角色绑定创建或更新的限制
例如，下面的 ClusterRole 和 RoleBinding 将允许用户 user-1 把名字空间 user-1-namespace 中的 admin、edit 和 view 角色赋予其他用户：
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: role-grantor rules: - apiGroups: ["rbac.authorization.k8s.io"] resources: ["rolebindings"] verbs: ["create"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["bind"] # 忽略 resourceNames 意味着允许绑定任何 ClusterRole resourceNames: ["admin","edit","view"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: role-grantor-binding namespace: user-1-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: role-grantor subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: user-1
当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要：
使用用户组为 system:masters 的凭据，该用户组由默认绑定关联到 cluster-admin 这个超级用户角色。
如果你的 API 服务器启动时启用了不安全端口（使用 --insecure-port）, 你也可以通过 该端口调用 API ，这样的操作会绕过身份验证或鉴权
