Kubernetes的RBAC权限控制
一、Role 和 ClusterRole
RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。这些权限是纯粹累加的（不存在拒绝某操作的规则）。
Role 用来在某个命名空间内设置访问权限；在你创建 Role时，你必须指定该 Role 所属的命名空间。
ClusterRole 则是一个集群作用域的资源，不需要指定命名空间。
role示例：
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" 标明 core API 组，一般情况下可留空 resources: ["pods"] # 对于pod的角色 verbs: ["get", "watch", "list"]
对于deployment的角色
rules: - apiGroups: ["extensions", "apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
允许读取核心 API 组中的 "pods" 和读/写 "batch" 或 "extensions" API 组中的 "jobs"
rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] - apiGroups: ["batch", "extensions"] resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
clusterrole示例：
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制 name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]
二、RoleBinding 和 ClusterRoleBinding
角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户（namespace）。它包含若干主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。
一个 RoleBinding 可以引用同一的命名空间中的任何Role。 或者一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的命名空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。
RoleBinding 示例：
下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 这样，用户 "jane" 就具有了读取 "default" 名字空间中 pods 的权限。
apiVersion: rbac.authorization.k8s.io/v1 # 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods kind: RoleBinding metadata: name: read-pods namespace: default subjects: # 你可以指定不止一个“subject（主体）” - kind: User name: jane # "name" 是区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系 kind: Role # 此字段必须是 Role 或 ClusterRole name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 apiGroup: rbac.authorization.k8s.io
用户alice@example.com
subjects: - kind: User name: "alice@example.com" 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
ClusterRoleBinding 示例：
要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。 下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 Secrets。
apiVersion: rbac.authorization.k8s.io/v1 # 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group name: manager # 'name' 是区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
三、在企业中的应用
kube-user：命名空间用于放置所有的系统用户user1、user2...
Cluster Role：定义如namespace list、POD delete、POD exec 、Deployment Create、Deployment update等权限
ClusterRoleBinding：用来绑定namespace list，可以显示所有的命名空间
Rolebinding：将user1绑定特定的角色如POD delete、POD exec等
需求：
1、用户leon可以查看default、kube-system下Pod的日志
2、用户feng可以在default下的Pod中执行命令，并且可以删除Pod
实现：
a. 首先创建kube-user命名空间：
kubectl create ns kube-user
b. 创建用户
kubectl create sa leon -n kube-user
kubectl create sa feng -n kube-user
c. 创建clusterrole相关角色
# cat clusterrole.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: namespace-read rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["metrics.k8s.io"] resources: ["pods"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-log rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-exec rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] - apiGroups: [""] resources: ["pods/exec"] verbs: ["create"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-del rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "delete"] # kubectl apply -f clusterrole.yaml
d. 为kube-user组绑定可查看全局namespace的权限
# cat namespace-read-sa-clusterrolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: namespace-read-sa subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts:kube-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: namespace-read # kubectl apply -f namespace-read-sa-clusterrolebinding.yaml
e. 将权限和用户进行绑定
kubectl create rolebinding leon-pod-log \ --clusterrole=pod-log --serviceaccount=kube-user:leon --namespace=kube-system kubectl create rolebinding leon-pod-log \ --clusterrole=pod-log --serviceaccount=kube-user:leon --namespace=default kubectl create rolebinding feng-pod-exec \ --clusterrole=pod-exec --serviceaccount=kube-user:feng --namespace=default kubectl create rolebinding feng-pod-del \ --clusterrole=pod-del --serviceaccount=kube-user:feng --namespace=default
f. 可以查看用户的token在k8s的dashboard中查看权限配置的是否正常
# kubectl get secret -n kube-user NAME TYPE DATA AGE default-token-sccck kubernetes.io/service-account-token 3 85m feng-token-5kpdf kubernetes.io/service-account-token 3 77m leon-token-2jj9g kubernetes.io/service-account-token 3 77m
# kubectl describe secret -n kube-user leon-token-2jj9g Name: leon-token-2jj9g Namespace: kube-user Labels: <none> Annotations: kubernetes.io/service-account.name: leon kubernetes.io/service-account.uid: 2027d6e6-e793-4d88-b471-80aab15fb604 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1066 bytes namespace: 9 bytes token: eyJhbGciOiJSUzI1NiIsImtpZCI6InI3ODFQaTBzR19OeUpMQnhNQm5Lem5GSlpjZ0VzWXNITGY5dHI2bVlOUjgifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibGVvbi10b2tlbi0yamo5ZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJsZW9uIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMjAyN2Q2ZTYtZTc5My00ZDg4LWI0NzEtODBhYWIxNWZiNjA0Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtdXNlcjpsZW9uIn0.y4ZJVxj3M3hhMPEEeS1033QYalMcI_dgZRTnKJvD_ykKYExKyGMYXtfOijubSnffHsMheX6e3lwcwA5NU2gTvzLZMy-uv-i7u4P7u5Kn69LpXLT8QSWBCHpvJBqaA5xssghJNDLjdsVw5va19cSFrsV06PtF3qeWn9wpKa7rqvyvwuK6xN-ijtNk26ZddcZ_FmvwVMjm3KCSUlsLjthpQK3eOekkVoNky8_ScPVme0INMYaT9rk8CFFC6MgCAhO_DYizJAw63UOreFRBkwRvJ7I1_fYF43ESjCNRwmfgnT8IxuqLExcbgUn_VPiKvA_AXqqsm5BEz8gbiY1yovviTQ
