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 getdeletelistupdate 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授权文件
页:
[1]