Kubernetes RBAC （Role-Based Access Control）

son30

基于角色访问控制RBAC
　　基于角色的访问控制（“RBAC”）使用rbac.authorization.k8s.ioAPI组来驱动授权决策，允许管理员通过Kubernetes API动态配置策略。
　　从Kubernetes 1.8开始，RBAC进入稳定版，其API为rbac.authorization.k8s.io/v1
　　要启用RBAC，请启动apiserver --authorization-mode=RBAC。
RBAC API Objects
　　一个基本的Kubernetes功能是，其所有资源都是API对象，允许CRUD（创建，读取，更新，删除）操作。资源是：

• 　　Pods.
  
• 　　PersistentVolumes.
  
• 　　ConfigMaps.
  
• 　　Deployments.
  
• 　　Nodes.
  
• 　　Secrets.
  
• 　　Namespaces.
  

　　资源与API组关联（例如，Pod属于核心 API组，而Deployments属于apps API组）。更多信息请查看官方Kubernetes API参考。
　　权限就是对某个资源可以执行什么样的操作，对应子命令是：
　　create get  delete  list  update edit watch exec
先做一个示例：
　　在这个例子中，我们将创建以下用户帐户：

• 　　用户名：test
  
• 　　组：gtest
  

　　我们使该用户只能在Office命名空间内拥有管理权
第1步：创建Office命名空间

• 　　执行kubectl create命令创建命名空间
  

kubectl create namespace office第2步：创建用户凭据

• 　　为您的用户创建一个私钥。employee.key
  

openssl genrsa -out employee.key 2048

• 　　使用刚刚创建的私钥创建一个证书签名请求employee.csr。确保你在-subj部分中指定了你的用户名和组（CN是用户名和O用于组）
  

openssl req -new -key employee.key -out employee.csr -subj "/CN=test/O=gtest"

• 　　使用现有集群CA来签署。生成访问群集API所需的证书。
  

openssl x509 -req -in employee.csr -CA /etc/kubernetes/ssl/ca.pem -CAkey /etc/kubernetes/ssl/ca-key.pem -CAcreateserial -out employee.crt -days 500

• 　　为Kubernetes集群添加新的上下文和证书。
  

kubectl config set-credentials employee --client-certificate=/home/employee/.certs/employee.crt  --client-key=/home/employee/.certs/employee.key　　kubectl config set-context employee-context --cluster=minikube --namespace=office --user=employee

• 　　现在使用此上下文时，应该会出现拒绝访问错误，因为我们还没有为这个用户定义任何允许的操作。
  

kubectl --context=employee-context get pods第3步：创建管理部署的角色

• 　　使用下面的内容创建一个role-deployment-manager.yaml文件。我们创建了一个rules，允许用户对Deployments，Pods和ReplicaSets进行相关操作
  

  kind: Role　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　namespace: office
　　name: deployment-manager
　　rules:
　　- apiGroups: ["", "extensions", "apps"]
　　resources: ["deployments", "replicasets", "pods"]
　　verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # You can also use ["*"]

• 　　使用kubectl create *命令在集群中创建role*：
  

kubectl create -f role-deployment-manager.yaml步骤4：将Role绑定到Test

• 　　创建一个rolebinding-deployment-manager.yaml文件。我们将角色绑定到office名称空间内的用户test
  

  kind: RoleBinding　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　name: deployment-manager-binding
　　namespace: office
　　subjects:
　　- kind: User
　　name: test
　　apiGroup: ""
　　roleRef:
　　kind: Role
　　name: deployment-manager
　　apiGroup: ""

• 　　通过运行kubectl create命令来部署RoleBinding ：
  

kubectl create -f rolebinding-deployment-manager.yaml第5步：测试RBAC

• 　　正常应该不会有任何问题
  

kubectl --context=employee-context run --image bitnami/dokuwiki mydokuwiki　　kubectl --context=employee-context get pods

• 　　测试操作其他名称空间
  

kubectl --context=employee-context get pods --namespace=defaultRBAC介绍：
Role and ClusterRole
　　在 RBAC API 中，Role 表示一组规则权限，权限只会增加(累加权限)，不存在一个资源一开始就有很多权限而通过 RBAC 对其进行减少的操作；Role 可以定义在一个 namespace 中，如果想要跨 namespace 则可以创建 ClusterRole。
　　Role 只能用于授予对单个命名空间中的资源访问权限， 以下是一个对默认命名空间中 Pods 具有访问权限的样例:
kind: Role　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　namespace: default
　　name: pod-reader
　　rules:
　　- apiGroups: [""] # "" indicates the core API group
　　resources: ["pods"]
　　verbs: ["get", "watch", "list"]
　　ClusterRole 具有与 Role 相同的权限角色控制能力，不同的是 ClusterRole 是集群级别的，ClusterRole 可以用于:

• 　　集群级别的资源控制(例如 node 访问权限)
  
• 　　非资源型 endpoints(例如 /healthz 访问)
  
• 　　所有命名空间资源控制(例如 pods)
  

　　以下是 ClusterRole 授权某个特定命名空间或全部命名空间(取决于绑定方式)访问 secrets 的样例
kind: ClusterRole　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　# "namespace" omitted since ClusterRoles are not namespaced
　　name: secret-reader
　　rules:
　　- apiGroups: [""]
　　resources: ["secrets"]
　　verbs: ["get", "watch", "list"]
RoleBinding and ClusterRoleBinding
　　RoloBinding 可以将角色中定义的权限授予用户或用户组，RoleBinding 包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users, groups, or service accounts)；RoloBinding 同样包含对被 Bind 的 Role 引用；RoleBinding 适用于某个命名空间内授权，而 ClusterRoleBinding 适用于集群范围内的授权。
　　RoleBinding 可以在同一命名空间中引用对应的 Role，以下 RoleBinding 样例将 default 命名空间的 pod-reader Role 授予 jane 用户，此后 jane 用户在 default 命名空间中将具有 pod-reader 的权限
# This role binding allows "jane" to read pods in the "default" namespace.　　kind: RoleBinding
　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　name: read-pods
　　namespace: default
　　subjects:
　　- kind: User
　　name: jane
　　apiGroup: rbac.authorization.k8s.io
　　roleRef:
　　kind: Role
　　name: pod-reader
　　apiGroup: rbac.authorization.k8s.io
　　RoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用
　　例如，以下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权用户 dave 只能访问 development 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)
# This role binding allows "dave" to read secrets in the "development" namespace.　　kind: RoleBinding
　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　name: read-secrets
　　namespace: development # This only grants permissions within the "development" namespace.
　　subjects:
　　- kind: User
　　name: dave
　　apiGroup: rbac.authorization.k8s.io
　　roleRef:
　　kind: ClusterRole
　　name: secret-reader
　　apiGroup: rbac.authorization.k8s.io
　　最后，使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding 样例展示了授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.　　kind: ClusterRoleBinding
　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　name: read-secrets-global
　　subjects:
　　- kind: Group
　　name: manager
　　apiGroup: rbac.authorization.k8s.io
　　roleRef:
　　kind: ClusterRole
　　name: secret-reader
　　apiGroup: rbac.authorization.k8s.io
Resources
　　Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在 API 的 URL 地址中出现；同时某些资源也会包含子资源，例如 logs 资源就属于 pods 的子资源，API 中 URL 样例如下
GET /api/v1/namespaces/{namespace}/pods/{name}/log　　如果要在 RBAC 授权模型中控制这些子资源的访问权限，可以通过 / 分隔符来实现，以下是一个定义 pods 资资源 logs 访问权限的 Role 定义样例
kind: Role　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　namespace: default
　　name: pod-and-pod-logs-reader
　　rules:
　　- apiGroups: [""]
　　resources: ["pods", "pods/log"]
　　verbs: ["get", "list"]
　　具体的资源引用可以通过 resourceNames 来定义，当指定 get、delete、update、patch 四个动词时，可以控制对其目标资源的相应动作；以下为限制一个 subject 对名称为 my-configmap 的 configmap 只能具有 get 和 update 权限的样例
kind: Role　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　metadata:
　　namespace: default
　　name: configmap-updater
　　rules:
　　- apiGroups: [""]
　　resources: ["configmap"]
　　resourceNames: ["my-configmap"]
　　verbs: ["update", "get"]
　　值得注意的是，当设定了 resourceNames 后，verbs 动词不能指定为 list、watch、create 和 deletecollection；因为这个具体的资源名称不在上面四个动词限定的请求 URL 地址中匹配到，最终会因为 URL 地址不匹配导致 Role 无法创建成功
Role Examples
　　以下样例只给出了 role 部分
　　在核心 API 组中允许读取 pods 资源
rules:　　- apiGroups: [""]
　　resources: ["pods"]
　　verbs: ["get", "list", "watch"]
　　在 extensions 和 apps API 组中允许读取/写入 deployments
rules:　　- apiGroups: ["extensions", "apps"]
　　resources: ["deployments"]
　　verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
　　允许读取 pods 资源，允许读取/写入 jobs 资源
rules:　　- apiGroups: [""]
　　resources: ["pods"]
　　verbs: ["get", "list", "watch"]
　　- apiGroups: ["batch", "extensions"]
　　resources: ["jobs"]
　　verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
　　允许读取名称为 my-config 的 ConfigMap(需要与 RoleBinding 绑定来限制某个特定命名空间和指定名字的 ConfigMap)
rules:　　- apiGroups: [""]
　　resources: ["configmaps"]
　　resourceNames: ["my-config"]
　　verbs: ["get"]
　　允许在核心组中读取 nodes 资源( Node 是集群范围内的资源，需要使用 ClusterRole 并且与 ClusterRoleBinding 绑定才能进行限制)
rules:　　- apiGroups: [""]
　　resources: ["nodes"]
　　verbs: ["get", "list", "watch"]
　　允许对非资源型 endpoint /healthz 和其子路径 /healthz/* 进行 GET 和 POST 请求(同样需要使用 ClusterRole 和 ClusterRoleBinding 才能生效)
rules:　　- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
　　verbs: ["get", "post"]
Subjects
　　RoleBinding 和 ClusterRoleBinding 可以将 Role 绑定到 Subjects；Subjects 可以是 groups、users 或者 service accounts。
　　Subjects 中 Users 使用字符串表示，它可以是一个普通的名字字符串，如 “alice”；也可以是 email 格式的邮箱地址，如 “bob@example.com”；甚至是一组字符串形式的数字>但是 Users 的前缀 system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式
　　Kubernetes 的 Group 信息目前由 Authenticator 模块提供，Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留
　　具有 system:serviceaccount: 前缀的用户名和 system:serviceaccounts: 前缀的组为 Service Accounts
Role Binding Examples
　　以下示例仅展示 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 namespace 中默认的 Service Account
subjects:　　- kind: ServiceAccount
　　name: default
　　namespace: kube-system
　　指定在 qa namespace 中全部的 Service Account
subjects:　　- kind: Group
　　name: system:serviceaccounts:qa
　　apiGroup: rbac.authorization.k8s.io
　　指定全部 namspace 中的全部 Service Account
subjects:　　- kind: Group
　　name: system:serviceaccounts
　　apiGroup: rbac.authorization.k8s.io
　　指定全部的 authenticated 用户(1.5+)
subjects: - kind: Group   name: system:authenticated   apiGroup: rbac.authorization.k8s.io　　指定全部的 unauthenticated 用户(1.5+)
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
相关链接

• 　　RBAC的官方Kubernetes文档
  
• 　　适用于RBAC的Google容器引擎文档
  
• 　　官方Kubernetes授权文件