Kubernetes RBAC （Role-Based Access Control）

基于角色访问控制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=default

RBAC介绍：

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 格式的邮箱地址，如 “[email protected]”；甚至是一组字符串形式的数字 ID。Users 的格式必须满足集群管理员配置的验证模块，RBAC 授权系统中没有对其做任何格式限定；但是 Users 的前缀 system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式

Kubernetes 的 Group 信息目前由 Authenticator 模块提供，Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留

具有 system:serviceaccount: 前缀的用户名和 system:serviceaccounts: 前缀的组为 Service Accounts

Role Binding Examples

以下示例仅展示 RoleBinding 的 subjects 部分

指定一个名字为 [email protected] 的用户

subjects:
- kind: User
  name: "[email protected]"
  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授权文件