参考：
● Kubernetes 管理员认证 (CKA)
● Kubernetes Certified Administration
1 管理基于角色的访问控制（RBAC）
难点 1：ClusterRole 定义的集群级别的角色，可通过 RoleBinding 在多个名字空间中复用
RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
name: secret-reader
rules:
- apiGroups: [""]
# 在 HTTP 层面，用来访问 Secret 对象的资源的名称为 "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
----
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
name: read-secrets
# RoleBinding 的名字空间决定了访问权限的授予范围。
# 这里隐含授权仅在 "development" 名字空间内的访问权限。
namespace: development
subjects:
- kind: User
name: dave # 'name' 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
2021 年 2 月真题：创建 ClusterRole 并绑定 ServiceAccount ，控制 Deployment、Statefulset 和 Daemonset 资源的访问
权限控制 RBAC 真题.png
apiVersion: v1
kind: ServiceAccount
metadata:
name: cicd-token
namespace: app-team1
-------
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: deployment-clusterrole
rules:
- apiGroups: [""]
resources: ["Deployment", "Statefulset", "Daemonset"]
verbs: ["create"]
-----
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cicd-rolebinding
namespace: app-team1
subjects:
- kind: ServiceAccount
name: cicd-token
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: deployment-clusterrole
apiGroup: rbac.authorization.k8s.io
