Kubernetes RBAC

RBAC (Role-Based Access Control) 基于角色的访问控制。

在 v1.5 中引入，在 v1.6 版本时升级为 Beta 版本，成为 kubeadm 安装方式下的默认选项，足见其重要程度。相对于其他的访问控制方式，新的 RBAC 具有如下优势。

• 对集群中的资源和非资源权限均有完整的覆盖。
• 整个 RBAC 完全由几个 API 对象完成，同其他 API 对象一样，可以用 kubectl 或 API 进行操作。
• 可以在运行时进行调整，无需重新启动 API Server。

要使用 RBAC 授权模式，则需要在 API Server 的启动参数中加入 --authorization-mode=RBAC。

下面对 RBAC 的原理和用法进行说明。

RBAC 的 API 资源对象说明

RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。同其他 API 资源对象一样，用户可以使用 kubectl 或者 API 调用等方式操作这些资源对象。

角色（Role）

一个角色就是一组权限的集合，这里的权限都是许可模式，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用 ClusterRole 了。

角色只能对命名空间内的资源进行授权，下面的例子中定义的角色具有读取 Pod 的权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 空字符串，表示核心 API 群
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

reule 中的参数说明如下：

• apiGroups：支持的 API 组列表，例如 “apiVersion: batch/v1” “apiVersion: extensions/v1beta1” "apiVersion: apps/v1beta1" 等。
• resource：支持的资源对象列表，例如 pods、deployments、jobs 等。
• verbs：对资源对象的操作方法列表，例如 get、watch、list、delete、replace、patch 等。

集群角色（Cluster Role）

集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。

• 集群范围的资源，例如 Node（节点）。
• 非资源型的路径，例如 “/healthz”。
• 包含全部命名空间的资源，例如 pods（用于 kubectl get pods --all-namespaces 这样的操作授权）。

下面的集群角色可以让用户有权访问任意一个或所有命名空间的 secrets（视其保定方式而定）：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # ClusterRole 不授权与命名空间，所以忽略了 namespace 的定义。
rules:
- apiGroups: [""] # "" 空字符串，表示核心 API 群
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）

角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，保定目标可以是 User（用户）、Group（组）或者 Service Account。使用 RoleBinding 为某个命名空间授权，使用 ClusterRoleBinding 为集群范围内授权。

RoleBinding 可以引用 Role 进行授权。下例中的 RoleBinding 将在 default 命名空间中把 pod-reader 角色授权用户 jane，这一操作让 jane 可以读取 default 命名空间中的 Pod：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: default
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroups: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroups: rbac.authorization.k8s.io

RoleBinding 也可以引用 ClusterRole，对属于同一命名空间内 ClusterRole 定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好了一组角色（ClusterRole），然后在多个命名空间中重复使用这些 ClusterRole。

例如下面的例子，虽然 secret-reader 是一个集群角色，但是因为使用了 RoleBinding，所以 dave 只能读取 development 命名空间的 secret：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development # 集群角色中，只有在 development namespace 中的权限才能赋予 dave
subjects:
- kind: User
  name: dave
  apiGroups: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroups: rbac.authorization.k8s.io

集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许 manager 组的用户读取任意 namespace 中的 secret：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroups: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroups: rbac.authorization.k8s.io

下图展示了对 Pod 的 get/watch/list 操作进行授权的 Role 和 RoleBinding 逻辑关系。

对资源的引用方式

多数资源可以用其名称的字符串来表达，也就是 Endpoint 中的 URL 相对路径，例如 pods。然而，某些 Kubernetes API 包含下级资源，例如 Pod 的日志（logs）。Pod 日志的 Endpoint 是 GET /api/v1/namespaces/{namespaces}/pod/{name}/log。

在这个例子中，Pod 是一个 namespace 内的资源，log 就是一个下级资源。要在一个 RBAC 角色中体现，则需要用斜线 “/” 来分隔资源和下级资源。若想授权让某个主题同时能够读取 Pod 和 Pod log，则可以配置 resources 为一个数组：

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"]
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]

可想而知，resourceName 这种用法对 list、watch、create 或 deletecollection 操作是无效的，这是因为必须要通过 URL 进行鉴权，而资源名称在 list、watch、create 或 deletecollection 请求中只是请求 Body 数据的一部分。

下面对场景的角色（Role）和角色绑定（RoleBinding）给出示例，提供参考用法。

常用的角色（Role）示例

1、允许读取核心 API 组中的 Pod 资源：

rule:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

2、允许读写 “extensions” 和 “apps” 两个 API 组中的 “deployment” 资源：

rule:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3、允许读取 “pods” 及读写 “jobs”:

rule:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

4、允许读取一个名为 “my-config” 的 ConfigMap（必须绑定到一个 RoleBinding 来限制到一个 namespace 下的 ConfigMap）：

rule:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

5、读取核心组的 “node” 资源（Node 属于集群级的资源，所以必须存在与 ClusterRole 中，并使用 ClusterRoleBinding 进行绑定）：

rule:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

6、允许对非资源端点 "/healthz" 及其所有子路径进行 “GET” 和 “POST” 操作（必须使用 ClusterRole 和 ClusterRoleBinding）：

rule:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]

常用的角色绑定（RoleBinding）示例

1、用户名 “alice@example.com”：

subjects:
- kind: User
  name: "alice@example.com"
  apiGroups: rbac.authorization.k8s.io

2、组名 “frontend-admins”

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroups: rbac.authorization.k8s.io

3、kube-system 命名空间中的默认 Service Account：

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

4、"qa" 命名空间中的所有 Service Account：

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroups: rbac.authorization.k8s.io

5、所有 Service Account：

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroups: rbac.authorization.k8s.io

6、所有认证用户（v1.5以上版本）

subjects:
- kind: Group
  name: system:authenticated
  apiGroups: rbac.authorization.k8s.io

7、所有未认证用户（v1.5以上版本）

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroups: rbac.authorization.k8s.io

8、全部用户（v1.5以上版本）

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroups: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroups: rbac.authorization.k8s.io

默认的角色和角色绑定

API Service 会创建一套默认的 ClusterRole 和 ClusterRoleBinding 对象，其中很多是以 “system” 为前缀的，以表明这些资源属于基础架构，对这些对象的改动可能造成集群故障。举例来说，system:node 这个 ClusterRole 为 kubelet 定义了权限，如果这个集群角色被改动了，则 kubelet 会停止工作。

所有默认的 ClusterRole 和 RoleBinding 都会用标签 kubernetes.io/bootstapping=reac-defaults 进行标记。

下面对默认的 ClusterRole 和 RoleBingding 对象进行说明。

对系统角色的说明如下表

对用户角色的说明如下表

有些默认角色不是以 "system:" 为前缀的，这部分角色是针对用户的。其中包含超级用户角色（cluster-admin），有的用于集群一级的角色（cluster-status），还有针对 namespace 的角色（admin, edit, view）。

用户角色表

核心 Master 组件角色说明表

其他组件角色说明表

Controller 角色说明表

Kubernetes Controller Manager 负责的是核心控制流。如果用 --use-service-account-credentials 调用，则每个控制过程都会使用不同的 Service Account 启动，因此就有了对应各个控制过程的角色。前缀是 system:controller。如果 Controlle Manager 没有用 --use-service-account-credentials 启动参数，则将使用自己的凭据允许各个控制流，这就需要为该凭据授予所有相关角色。

授权注意事项: 预防提权和授权初始化

RBAC API 拒绝用户利用编辑角色或者角色绑定的方式进行提权。这一限制是在 API 层面作出的，因此即使 RBAC 没有启用也仍然有效。

用户只能在拥有一个角色的所有权限，且与该角色的生效范围一致（如果是集群角色，则是集群范围；如果是普通角色，则可能是同一 namespace 或全集群）的前提下，才能对角色进行创建和更新。例如用户 user-1 没有列出集群中所有 secret 的权限，就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色，需要：

• 为其授权一个允许 创建/更新 Role 或 ClusterRole 资源对象的角色。
• 为用户授权角色，要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或者集群角色，则该 API 调用会被禁止。

如果一个用户的权限包含了一个角色的所有权限，那么就可以为其创建和更新角色绑定（要求同样的作用范围）；或者如果被授予了针对某个角色的绑定授权，则也有权完成此操作。例如，如果用户 user-1 没有列出集群内所有 secret 的权限，就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定，则需要有如下做法。

• 为其授权一个允许创建和更新角色绑定或者集群角色绑定的角色。
• 为其授权绑定某一个角色的权限，有隐式或显式两种方法。
  隐式：让其具有所有该角色的权限。
  显式：为用户授权针对该角色（或集群角色）的绑定操作的权限。

例如，下面的集群角色和角色绑定能让 user-1 为其他用户在 user-1-namespace 中授予 admin、edit 及 view 角色：

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["admin", "edit", "view"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroups: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroups: rbac.authorization.k8s.io
  kind: User
  name: user-1

在进行第一个角色和角色绑定时，必须让初始用户具备其尚未被授予的权限，要进行初始的角色和角色绑定设置，有以下两种办法。

• 使用属于 system:masters 组的身份，这一群组默认具有 cluster-admin 这一超级角色的绑定。
• 如果 API Service 以 --insecure-port 参数运行，则客户端通过这个非安全端口进行接口调用，这一端口没有认证鉴权的限制。

对 Service Account 的权限管理

默认的 RBAC 策略为控制平台组件、节点和控制器授予有限范围的权限，但是在 “kube-system” 之外的 Service Account 是没有任何权限的（除了所有认证用户都具有的 discovery 权限）。

这就要求用户为 Service Account 赋予所需的权限。细粒度的角色分配能够提高安全性，但也会提高管理成本。粗放的授权方式可能会给 Service Account 多余的权限，但会更容易管理。

下面的实践以安全性递减的方式排序。

1、为一个应用专属的 Service Account 授权（最佳实践）。

这个应用需要在 Pod 的 Spec 中指定一个 serviceAccountName，用 API、Application Manifest、kubectl create serviceaccount 命令等创建 Service Account，例如为 “my-namespace” 中的 “my-sa" Service Account 授权只读权限：(需要有 my-namespace 这个命名空间才可以创建否则会报错)

$ kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

2、为一个 namespace 中的 ”default“ Service Account 授权。

如果一个应用没有指定 serviceAccountName，则会使用 ”default“ Service Account。注意，赋给 ”default“ Service Account 的授权会让所有没指定 serviceAccountName 的 Pod 都具有这些权限。

例如在 ”my-namespace“ 命名空间里为 ”default“ Service Account 赋予只读权限：

$ kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

目前不少 Add-Ons 在 ”kube-system“ 命名空间中用 ”default“ Service Account 运行。要让这些 Add-Ons 能够使用超级用户权限，则可以把 cluster-admin 授权赋予 ”kube-system“ 的 ”default“ Service Account。注意，这一操作意味着 ”kube-system" 命名空间包含了通向 API 超级用户的捷径：

$ kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

3、为命名空间内的所有 Service Account 授予一个角色。

如果希望在一个命名空间里，任何 Service Account 的应用都具有一个角色，则可以为这一命名空间的 Service Account 群组进行授权。

例如，为 “my-namespace" 命名空间中的所有 Service Account 赋予只读权限：

$ kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

4、为集群范围内的所有 Service Account 授予一个低权限角色（不推荐）。

如果不想为每个命名空间管理权限，则可以把一个集群级别的角色赋给所有 Service Account。

例如，为所有命名空间中的所有 Service Account 授予只读权限：

$ kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts

5、为所有 Service Account 授予超级用户权限（强烈不建议这样设置）。

如果完全不在意权限，则可以把超级用户权限分配给每一个 Service Account。

$ kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

使用 kubectl 命令行工具创建资源对象

除了使用 yaml 配置文件来创建这些资源对象，也可以直接使用 kubectl 命令行工具对它们进行创建。下面通过几个例子进行说明。

1、在命名空间 acme 内为用户 bob 授权 admin  ClusterRole：

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

2、在命名空间 acme 内为名为 myapp 的 Service Account 授予 view ClusterRole：

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=accme:myapp --namespace=acme

3、在全集群范围内为用户 ”root“ 授予 cluster-admin ClusterRole:

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

4、在全集群范围内为用户 ”kubelet“ 授予 system:node ClusterRole:

$ kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

5、在全集群范围内为名为 ”myapp“ 的 Service Account 授予 view ClusterRole:

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

RBAC 的 Auto-reconciliation（自动恢复）功能

自动回复从 v1.6 版本开始引入。每次启动时，API Server 都会更新默认的集群角色的缺失权限，也会刷新默认的角色绑定中缺失的主体，这样就防止了一些破坏性的修改，也保证了在集群升级的情况下相关内容能够及时更新。

如果不需要使用这一功能，则可以将一个默认的集群角色（ClusterRole）或者角色绑定（RoleBinding）的 Annoration 注解 ”rbac.authorization.kubernetes.io/autoupdate“ 值设置为 false。

从旧版本的策略升级到 RBAC

在 v1.6 之前，很多 Deployment 都试用了比较宽松的 ABAC 策略，包含为所有 Service Account 开放完全 API 访问。

默认的 RBAC 策略为控制台组件、节点和控制器授予了范围受限的权限，但是不会为 ”kube-system“ 以外的 Service Account 授予任何权限。

这样一来，可能会对现有的一些工作负载造成影响，这时用两种办法来解决这一问题。

1、并行认证。RBAC 和 ABAC 同时允许，并包含传统的 ABAC 策略：

--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl

首先会由 RBAC 尝试对请求进行授权，如果得到的结果是拒绝，那么就轮到了 ABAC 生效。这样所有应用只要满足 RBAC 或 ABAC 之一即可工作。

如果使用 2 或者更高的日志标准（--v=2），则将可以在 API Server 日志中看到 RBAC 的拒绝行为（前缀：RBAC DENY）。可以利用这一信息来确定需要授权任何权限给用户、组或 Service Account。如果有一天，集群管理员已经按照 RBAC 的方式对 Service 进行授权，并且这些工作负载运行的过程中不再出现 RBAC 的拒绝信息，就可以移除 RBAC 了。

1、粗放管理。可以使用 RBAC 的角色绑定，复制一个粗放的策略。

$ kubectl create clusterrolebinding pemissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts