Kubernetes权限管理之RBAC

K8s在1.3版本中发布了alpha版的基于角色的访问控制RBAC（Role-based Access Control）的授权模式。相对于基于属性的访问控制ABAC（Attribute-based Access Control），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联。

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

新的RBAC具有如下优势。

• 对集群中的资源和非资源权限均有完整的覆盖。
• 整个RBAC完全由 几个API对象完成，同其他API对象一样 ，可以用kubectl或API进行操作。
• 可以在运行时进行调整，无须重新启动 API Server。
• 要使用 RBAC 授权模式 ，则 需要在 API Server 的启动 参数中 加上--authorization-mode=RBAC。

角色( 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"]

rules 中的参数说明如下：

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

集群角色（ClusterRole）

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

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

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

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # ClusterRole不受限于命名空间，所以省略了namespace name的定义
rules:
- apiGroups: [""]
  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: 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进行授权。

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命名空间中的权限才能赋予dave
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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

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

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

2）对资源的引用方式

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

在这个例子中，Pod是一个命名空间内的资源，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"]

资源还可以通过名字（ResourceName）进行引用（这里指的是资源实例的名子）。在指定ResourceName后，使用get、delete、update和patch动词的请求，就会被限制在这个资源实例的范围内。

例如下面的声明让一个主体只能对一个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"]

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

3）常用的角色（Role）示例

下面的例子只展示了rules部分的内容。

（1）允许读取核心API组中的Pod资源

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

（2）允许读写"extensions"和"apps"两个API组中的"deployments"资源

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

（3）允许读取"pods"及读写"jobs"

rules:
- 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）

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

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

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

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

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

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

注意，下面的例子中只包含subjects部分的内容。

（1）用户名"alice@example.com"

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

（2）组名"frontend-admins"

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: 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
  apiGroup: rbac.authorization.k8s.io

（5）所有Service Account

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

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

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

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

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

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

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

5）默认的角色和角色绑定

API Server 创建了一系列的默认 ClusterRole 和 ClusterRoleBinding 对象， 其中许多对象以 "system:" 前缀开头，代表其中绑定的资源是作为基础设施适用和占有的。修改这些资源会导致整个集群不可用。一个例子是 system:node 。这个ClusterRole角色拥有一系列的kubelet权限，如果这个集群角色被修改了，可能会让kubelet出现异常。

所有默认的集群角色 （ClusterRole） 和其角色绑定（role binding）都带有如下标记

kubernetes.io/bootstrapping=rbac-defaults

下面对一些常见的默认ClusterRole和ClusterRoleBinding对象进行说明。

对系统角色的说明如下表所示：

默认的ClusterRole	默认的ClusterRoleBinding	描述
system:basic-user	system:authenticated和system:unauthenticated组	让用户能够读取自身的信息
system:discovery	system:authenticated和system:unauthenticated组	对API发现Endpoint的只读访问，用于API级别的发现和协商

对用户角色的说明如下表所示：

默认的ClusterRole	默认的ClusterRoleBinding	描述
cluster-admin	system:masters组	让超级用户可以对任何资源执行任何操作。如果在ClusterRoleBinding中使用，则影响的是整个集群的所有namespace中的任何资源；如果使用的是RoleBinding，则能控制这一绑定的namespace中的资源，还包括namespace本身。
cluster-status	None	可以对基础集群状态信息进行只读访问。
admin	None	允许admin访问，可以限制在一个namespace中使用RoleBinding。如果在RoleBinding中使用，则允许对namespace中大多数资源进行读写访问，其中包含创建角色和角色绑定的能力。这一角色不允许操作namespace本身，也不能写入资源限额。
edit	None	允许对命名空间内的大多数资源进行读写操作，不允许查看或修改角色，以及角色绑定。
view	None	允许对多数对象进行只读操作，但是对角色、角色绑定及secret是不可访问的。

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

对核心Master组件角色的说明如下表所示：

默认的ClusterRole	默认的ClusterRoleBinding	描述
system:kube-scheduler	system:kube-scheduler用户	能够访问kube-scheduler组件所需的资源
system:kube-controller-manager	system:kube-controller-manager用户	能够访问kube-controller-manager组件所需的资源，不同的控制所需的不同权限参见下表。
system:node	system:nodes组	允许访问kubelet所需的资源，包括对secret的读取，以及对Pod的写入。未来会把上面的两个权限限制在分配到本Node的对象上。今后的鉴权过程，kubelet必须以system:node及一个system:node形式的用户名进行。参看https://pr.k8s.io/40476
system:node-proxier	system:kube-proxy用户	允许访问kube-proxy所需的资源
system:kube-scheduler	system:kube-scheduler用户	能够访问kube-scheduler组件所需的资源

对其他组件角色的说明如下表所示：

默认的ClusterRole	默认的ClusterRoleBinding	描述
system:auth-delegator	None	允许对授权和认证进行托管，通常用于附加的API服务器
system:heapster	None	Heapster组件的角色
system:kube-aggregator	None	kube-aggregator的角色
system:kube-dns	在kube-system namespace中kube-dns的Service Account	kube-dns角色
system:node-bootstrapper	None	允许访问kubelet TLS启动所需的资源
system:node-problem-detector	None	允许访问node-problem-detector组件所需的资源
system:persistent-volume-provisioner	None	允许访问多数动态卷供给所需的资源

对Controller角色的说明如下表所示：

Controller角色
system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:generic-garbage-collector
system:controller:horizontal-pod-autoscaler
system:controller:job-controller
system:controller:namespace-controller
system:controller:node-controller
system:controller:persistent-volume-binder
system:controller:pod-garbage-collector
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller

K8s Controller Manager负责的是核心控制流。如果启用--user-service-account-credentials，则每个控制过程都会使用不同的Service Account启动。因此就有了对应各个控制过程的角色，前缀是system:controller。如果未启用这一功能，则将使用各自的凭据运行各个控制流程，这就需要为该凭据授予所有相关角色。

6）授权注意事项：预防提权和授权初始化

RBAC API拒绝用户利用编辑角色或者角色绑定的方法进行提权。这一限制是在API层面做出的，因此即使RBAC没有启动也仍然有效。
用户只能在拥有一个角色的所有权限，且与该角色的生效范围一致的前提下，才能对角色进行创建和更新。要让一个用户能够创建或更新角色，需要：

• 为其授予一个允许创建/更新Role或ClusterRole资源对象的角色；

• 为用户授予角色，要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或集群角色，则该API调用会被禁止。

如果一个用户的权限包含了一个角色的所有权限，那么就可以为其创建和更新角色绑定。或者如果被授予了针对某个角色的绑定授权，则也有权完成此操作。

要使用户能够创建、更新这一角色绑定或者集群角色绑定的角色，需要有如下做法：

• 为其授予一个允许其创建和更新角色绑定或者集群角色绑定的角色；
• 为其授予绑定某一角色的权限。

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

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

7）对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授予只读权限：

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

（2）为一个命名空间中的"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授予一个角色

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

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

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

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

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

（5）为所有Service Account授予超级用户权限（非常危险）

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

8）使用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=acme: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

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

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

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

10）从旧版本的授权策略升级到RBAC

在k8s 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之一即可工作。
通过输出更详细的日志信息，查看以上鉴权过程和结果。直到某一天，再也不输出RBAC鉴权失败的日志了，就可以移除ABAC了。

（2）粗放管理

可以使用RBAC的角色绑定，复制一个粗话的策略。

下面的策略会让所有Service Account都具备了集群管理员权限，所有容器运行的应用都会自动接收到Service Account的认证，能够对任何API做任何事情，包括查看Secret和修改授权。这一策略无疑是比较凶险的。

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