RBAC授权模式详解
RBAC（Role-Based Access Control，基于角色的访问控制）在Kubernetes的1.5版本中引入，在1.6版本时升级为Beta版本，在1.8版本时升级为GA。作为Kubeadm安装方式的默认选项，足见其重要程度。相对于其他访问控制方式，新的RBAC具有如下优势。
- 对集群中的资源和非资源权限均有完整的覆盖。
- 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作。
- 可以在运行时进行调整，无须重新启动API Server。
要使用RBAC授权模式，需要在API Server的启动参数中加入-authorization-mode=RBAC.
下面对RBAC的原理和永华进行说明。
1.RBAC的API资源对象说明
RBAC引入了4个新的顶级资源对象： Role、ClusterRole、RoleBinding和ClusterRoleBinding。同其他API资源对象一样，用户可以使用kubectl或者API调用等方式操作这些资源对象。
** 1）角色（Role）**
一个角色就是一个组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了。
角色只能对命名空间内的资源进行授权，在下面例子中定义的角色具备读取Pod的权限：
2
3
4
5
6
7
8
9
10
11
2apiVersion: rbac.authorization.k8s.io/v1
3metadata:
4 namespace: default
5 name: pod-reader
6rules:
7- apiGroups: [""] # "" 空字符串，表示核心API群
8 resources: ["pods"]
9 verbs: ["get", "watch", "list"]
10
11
rules中的参数说明如下：
apiGroups: 支持的API组列表，例如“apiVersion:batch/v1” "apiVersion:extensions:v1beta1" "apiVersion:apps/v1beta1"等。
resources: 支持的资源对象列表，例如pods、deployments、jobs等。
verbs： 对资源对象的操作方法列表，例如get、watch、list、delete、replace、patch等。
2） 集群角色（ClusterRole）
集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。
- 集群范围的资源，例如Node。
- 非资源的路径，例如“/healthz”。
- 包含全部命名空间的资源，例如pods（用于kubectl get pods –all-namespaces这样的操作授权）。
下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets（视其绑定方式而定）：
2
3
4
5
6
7
8
9
2apiVersion: rbac.authorization.k8s.io/v1
3metadata:
4 # ClusterRole 不受限于命名空间，所以无须设置Namespace的名称
5rules:
6- apiGroups: [""]
7 resources: ["secrets"]
8 verbs: ["get","watch","list"]
9
3)角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）
角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，绑定目标可以是User（用户），Group（组）或者Service Account。 使用RoleBinding为某个命名空间授权，使用ClusterRoleBinding为集群范围内授权。
RoleBinding可以引用Role进行授权，下面的例子中的Rolebinding将在default命令空间中把pod-reader角色授予用户jane，这易操作可以让jane读取default命令空间中的Pod：
2
3
4
5
6
7
8
9
10
11
12
13
14
2apiVersion: rbac.authorization.k8s.io/v1
3metadata:
4 name: read-pods
5 namespace: default
6subjects:
7- kind: User
8 name: jane
9 apiGroup: rbac.authorization.k8s.io
10roleRef:
11 kind: Role
12 name: pod-reader
13 apiGroup: rbac.authorization.k8s.io
14
集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许manager组的用户读取任意Namespace中的secret：
2
3
4
5
6
7
8
9
10
11
12
13
2apiVersion: rbac.authorization.k8s.io/v1
3metadata:
4 name: read-secrets-global
5subjects:
6- kind: Group
7 name: manager
8 apiGroup: rbac.authorization.k8s.io
9roleRef:
10 kind: ClusterRole
11 name: secret-reader
12 apiGroup: rbac.authorization.k8s.io
13
![带你玩转kubernetes-k8s（第39篇：深入分析集群安全机制二[RBAC授权模式]）](https://aqzt.com/wp-content/uploads/20220210134111-58.png)
上图展示了上述对Pod的get/watch/list操作进行授权的Role和RoleBinding逻辑关系。
2.对资源的引用方式
多数资源可以用其名称的字符串来表达，也就是Endpoint中的URL相对路径，例如pods。然而，某些Kubernetes API包含下级资源，例如Pod的日志（logs）。Pod日志的Endpoint是GET/ api/v1/namespaces/{namespace}/pods/{name}/log。
在这个例子中，Pod是一个命名空间内的资源，log就是一个下级资源。要在一个RBAC角色中体现，就需要用斜线“/”来分隔资源和下级资源。若想授权让某个主体同时能够读取Pod和Pod log，则可以配置resources为一个数组：
2
3
4
5
6
7
8
9
10
2apiVersion: rbac.authorization.k8s.io/v1
3metadata:
4 namespace: default
5 name: pod-and-pod-logs-reader
6rules:
7- apiGroups: [""]
8 resources: ["pods", "pods/log"]
9 verbs: ["get", "list"]
10
资源还可以通过名称（ResourceName）进行引用。在指定ResourceName后，使用get、delete、update和patch动词的请求，就会被限制在这个资源实例范围内。例如，下面的声明让一个主体只能对一个ConFigmap进行get和update操作：
2
3
4
5
6
7
8
9
10
11
2apiVersion: rbac.authorization.k8s.io/v1
3metadata:
4 namespace: default
5 name: configmap-updater
6rules:
7- apiGroups: [""]
8 resources: ["configmap"]
9 resourceNames: ["my-configmap"]
10 verbs: ["update", "get"]
11
可想而知，resourceName这种用法对list、watch、create或deletecollection操作是无效的，这是因为必须要通过URL进行鉴权，而资源名称在list、watch、create或deletecollection请求中只是请求Body数据的一部分。
下面对常见的角色和角色绑定给出示例，提供参考用法。
3.常用的角色示例
注意，下面的例子只展示了rules部分的内容。
（1） 允许读取核心API组中的Pod资源：
2
3
4
5
6
2- apiGroups: [""]
3 resources: ["pods"]
4 verbs: ["get","list","watch"]
5
6
(2) 允许读写extensions和apps两个API组中的deployment资源：
2
3
4
5
2- apiGroups: ["extensions", "apps"]
3 resources: ["deployments"]
4 verbs: ["get","list","watch","create","update","patch","delete"]
5
(3) 允许读取pods及读写jobs:
2
3
4
5
6
7
8
2- apiGroups: [""]
3 resources: ["pods"]
4 verbs: ["get","list","watch"]
5- apiGroups: ["batch", "extensions"]
6 resources: ["jobs"]
7 verbs: ["get","list","watch","create","update","patch","delete"]
8
(4) 允许读取一个名为my-config的ConfigMap（必须绑定到一个RoleBinding来限制到一个Namespace下的ConfigMap)：
2
3
4
5
6
2- apiGroups: [""]
3 resources: ["configmaps"]
4 resourceNames: ["my-config"]
5 verbs: ["get"]
6
(5) 读取核心组的Node资源（Node属于集群级的资源，所以必须存在于ClusterRole中，并使用ClusterRoleBinding进行绑定）：
2
3
4
5
2- apiGroups: [""]
3 resources: ["nodes"]
4 verbs: ["get","list","watch"]
5
(6) 允许对非资源端点“/healthz”及其所有子路径进行GET和POST操作（必须使用ClusterRole和ClusterRoleBinding）:
2
3
4
2- nonResourceURLs: ["/healthz","/healthz/*"]
3 verbs: ["get","post"]
4
4.常见的角色绑定示例
注意，在下面例子中只包含subjects部分的内容。
（1）用户名alice@example.com：
2
3
4
5
6
2- kind: User
3 name: "alice@example.com"
4 apiGroup: rbac.authorization.k8s.io
5
6
(2) 组名frontend-admins：
2
3
4
5
2- kind: Group
3 name: "frontend-admins"
4 apiGroup: rbac.authorization.k8s.io
5
(3) kube-system命令空间中的默认Service Account：
2
3
4
5
2- kind: ServiceAccount
3 name: default
4 namespace: kube-system
5
(4) qa命名空间中的所有Service Account：
2
3
4
5
2- kind: Group
3 name: system.serviceaccounts:qa
4 apiGroup: rbac.authorization.k8s.io
5
(5) 所有Service Account：
2
3
4
5
2- kind: Group
3 name: system.serviceaccounts
4 apiGroup: rbac.authorization.k8s.io
5
(6) 所有认证用户（kuberetes1.5以上版本）:
2
3
4
5
2- kind: Group
3 name: system:authenticated
4 apiGroup: rbac.authorization.k8s.io
5
(7) 所有未认证用户（kubernetes1.5以上版本）：
2
3
4
5
2- kind: Group
3 name: system:unauthenticated
4 apiGroup: rbac.authorization.k8s.io
5
(8) 全部用户（kubernetes1.5以上版本）：
2
3
4
5
6
7
8
2- kind: Group
3 name: system:authenticated
4 apiGroup: rbac.authorization.k8s.io
5- kind: Group
6 name: system:unauthenticated
7 apiGroup: rbac.authorization.k8s.io
8
5. 默认的角色和角色绑定
API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象，其中很多是以“system：”为前缀的，以表明这些资源属于基础架构，对这些对象的改动可能造成集群故障。举例来说，system:node这个ClusterRole为kubelet定义了权限，如果这个集群角色被改动了，kubelet就会停止工作。
所有默认的ClusterRole和RoleBinding都会用标签kubernetes.io/bootstrapping=rbac-defaults进行标记。
下面对一些常见的默认ClusterRole和ClusterRoleBinding对象进行说明。
对系统角色的说明如下表所示。
system:basic-user
system:authenticated
让用户能够读取自身的信息（在k8s1.14版本之前，还绑定了system:unauthenticated组）
system:discovery
system:authenticated
队API发现Endpoint的只读访问，用于API级别的发现和协商（在k8s1.14版本之前还绑定了system：unauthenticated组）
system:public-info-viewr
system:authenticated与 system:unauthenticated 组
允许读取集群的非敏感信息（从k8s1.14开始引入）
对用户角色的说明如下表所示。有些默认角色不是以“system：” 为前缀的，这部分角色是针对用户的。其中包含超级用户角色（cluster-admin），有的用于集群一级的角色（cluster-status），还有针对Namespace的角色（admin、edit、view）。
cluster-admin
system:master组
让超级用户可以对任何资源执行任何操作，如果在ClusterRoleBinding中使用，则影响的是整个集群所有namespace中的任何资源；如果使用的是RoleBinding，则能控制这一绑定的Namespace中的资源，还包含Namespace本身
admin
None
允许admin访问，可以限制在一个Namespace中使用RoleBinding。如果在RoleBinding中使用，则允许对Namespace中的大多数资源进行读写访问，其中包含创建角色和角色绑定的能力。这一角色不允许操作Namespace本身，也不能写入资源限额
edit
None
允许对命令空间中的大多数资源进行读写操作，不允许查看或修改角色，以及角色绑定
view
None
允许对多数对象进行只读操作，但是对角色、角色绑定及secret是不可访问的
对核心Master组件角色的说明如下表：
system:kube-sheduler
system:kube-scheduler用户
能够访问kube-scheduler组件所需的资源
system:volume-sheduler
system: kube-scheduler用户
允许kube-sheduler组件访问Volume资源
system:kube-controller-manager
system:kube-controller-manager用户
能够访问kube-controller-manager组件所需的资源。
system:node
None
允许访问kubelet组件所需的资源，包括所有secret的读取，以及对所有Pod状态的写访问。从Kubernetes1.8版本开始，就没有自动绑定过程了。
system:node-proxier
system:kube-prixy用户
允许访问kube-proxy所需的资源
对其他组件角色的说明如下表所示：
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:kubelet-api-admin
None
允许对kubeket API 的完全访问
system:node-bootstrapper
None
允许访问kubelet TLS启动所需的资源
system:node-problem-detector
None
允许访问node-problem-detector组件所需的资源
system:persistent-volume-provisioner
None
允许访问多数动态卷供给所有资源
system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:clusterrole-aggregation-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:expand-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-bider
system:controller:pod-garbage-collector
system:controller:pv-protection-controller
system:controller:pvc-protection-controller
system:controller:replication-controller
system:controller:replicaset-controller
system:controller:resourcequota-controller
system:controller:root-ca-cert-publisher
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller
Kubernetes Controller Manager负责的是核心控制流。如果用–use-service-accountcredentials调用，则每个控制过程都会使用不同的Service Account启动，因此就有了对应各个控制过程的角色，前缀是system:controller。如果Controller Manager没有用–use-service-account-credentials启动参数，则将使用自己的凭据运行各个控制流程，这就需要为该凭据授予所有相关角色。
6.授权注意实现：预防提升权限和授权初始化
RBAC API拒绝用户通过编辑角色或者角色绑定进行提升权限。这一限制是在API层面做出的，因此即使RBAC没有启用也仍然有效。
用户要对角色进行创建或更新操作，需要满足下列至少一个条件：
（1）拥有一个角色的所有权限，且与该角色的生效范围一致（如果是集群角色，则是集群范围；如果是普通角色，则可能是同一个命名空间或者整个集群）；
（2）为用户显式授予针对该角色或集群角色的提权（escalate）操作的权限（要求Kubernetes 1.12及以上版本）。
例如，用户user-1没有列出集群中所有secret的权限，就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色，需要：
（1）为其授予一个允许创建或更新Role或ClusterRole资源对象的角色；
（2）为其授予绑定某一角色的权限，有隐式或显式两种方法。
◎ 隐式：为用户授予权限，要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或者集群角色，则该API调用会被禁止。
◎ 显式：为用户显式授予针对该Role或ClusterRole的提权（Escalate）操作的权限（要求Kubernetes 1.12及以上版本）。
如果一个用户的权限包含一个角色的所有权限，就可以为其创建和更新角色绑定（要求同样的作用范围）；或者如果被授予了针对某个角色的绑定授权，则也有权完成此操作。例如，如果用户user-1没有列出集群内所有secret的权限，就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定，则需要这样做，如下所述。
（1）为其授予一个允许创建和更新RoleBinding或ClusterRoleBinding的角色。
（2）为其授予绑定某一角色的权限，有隐式或显式两种方法。
◎ 隐式：让其具有该角色的所有权限。
◎ 显式：为用户授予针对该角色（或集群角色）的绑定操作的权限。
例如，下面的集群角色和角色绑定能让user-1为其他用户在user-1-namespace命名空间中授予admin、edit及view角色：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2kind: ClusterRole
3metadata:
4 name: role-grantor
5rules:
6- apiGroups: ["rbac.authorization.k8s.io"]
7 resources: ["rolebindings"]
8 verbs: ["create"]
9- apiGroups: ["rbac.authorization.k8s.io"]
10 resources: ["clusterroles"]
11 verbs: ["bind"]
12 resourceName: ["admin","edit","view"]
13---
14apiVersion: rbac.authorization.k8s.io/v1
15kind: RoleBinding
16metadata:
17 name: role-grantor-binding
18 namespace: user-1-namespace
19roleRef:
20 apiGroup: rbac.authorization.k8s.io
21 kind: ClusterRole
22 name: role-grantor
23subjects:
24- apiGroup: rbac.authorization.k8s.io
25 kind: User
26 name: user-1
27
在进行第1个角色和角色绑定时，必须让初始用户具备其尚未被授予的权限。要进行初始的角色和角色绑定设置，有以下两种办法。
（1）使用属于system:masters组的身份，这一群组默认具有cluster-admin这一超级角色的绑定。
（2）如果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授予只读权限：
2
3
4
5
2--clusterrole=view \
3--serviceaccount=my-namespace:my-sa \
4--namespace=my-namespace
5
（2）为一个命名空间中名为default的Service Account授权。
如果一个应用没有指定serviceAccountName，则会使用名为default的Service Account。注意，赋给Service Account“default”的权限会让所有没有指定serviceAccountName的Pod都具有这些权限。
例如，在my-namespace命名空间中为Service Account“default”授予只读权限：
2
3
4
2--clusterrole=cluster-admin \
3--group=system:serviceaccounts
4
另外，许多系统级Add-Ons都需要在kube-system命名空间中运行。要让这些Add-Ons能够使用超级用户权限，则可以把cluster-admin权限赋予kube-system命名空间中名为default的Service Account。注意，这一操作意味着kube-system命名空间包含了通向API超级用户的捷径：
2
3
4
2--clusterrole=cluster-admin \
3--serviceaccount=kube-system:default
4
（3）为命名空间中的所有Service Account都授予一个角色。
如果希望在一个命名空间中，任何Service Account的应用都具有一个角色，则可以为这一命名空间的Service Account群组进行授权。
例如，为my-namespace命名空间中的所有Service Account赋予只读权限：
2
3
4
5
2--clusterrole=view \
3--group=system:serviceaccounts:my-namespace \
4--namespace=my-namespace
5
（4）为集群范围内的所有Service Account都授予一个低权限角色（不推荐）。
如果不想为每个命名空间管理授权，则可以把一个集群级别的角色赋给所有Service Account。
例如，为所有命名空间中的所有Service Account授予只读权限：
2
3
4
2--clusterrole=view \
3--group=system:serviceaccounts
4
（5）为所有Service Account授予超级用户权限（强烈不建议这样设置）。
如果完全不在意权限，则可以把超级用户权限分配给每个Service Account。
注意，这让所有具有读取Secret权限的用户都可以创建Pod来访问超级用户的专属权限：
2
3
4
2--clusterrole=view \
3--group=system:serviceaccounts
4
8. 使用kubectl命令工具创建资源对象
除了使用YAML配置文件来创建这些资源对象，也可以直接使用kubectl命令行工具对它们进行创建。下面通过几个例子进行说明。
（1）在命名空间acme中为用户bob授权admin ClusterRole：
2
2
（2）在命名空间acme中为名为myapp的Service Account授予view ClusterRole:
2
2
（3）在全集群范围内为用户root授予cluster-admin ClusterRole：
2
2
（4）在全集群范围内为用户kubelet授予system:node ClusterRole：
2
2
（5）在全集群范围内为名为myapp的Service Account授予view ClusterRole：
2
2
可以在kubectl –help的帮助中查看更详细的说明。
9.RBAC的Auto-reconciliation（自动恢复）功能
自动恢复从Kubernetes 1.6版本开始引入。每次启动时，API Server都会更新默认的集群角色的缺失权限，也会刷新在默认的角色绑定中缺失的主体，这样就防止了一些破坏性的修改，也保证了在集群升级的情况下相关内容能够及时更新。
如果不希望使用这一功能，则可以将一个默认的集群角色或者角色绑定的Annotation注解“rbac.authorization.kubernetes.io/autoupdate”值设置为false。
10.从旧版本的授权策略升级到RBAC
在Kubernetes 1.6之前，很多Deployment都试用了比较宽松的ABAC策略，包含为所有Service Account都开放完全API访问权限。
默认的RBAC策略为控制台组件、节点和控制器授予了范围受限的权限，但是不会为kube-system以外的Service Account授予任何权限。
这样一来，可能会对现有的一些工作负载造成影响，这时有两种办法来解决这一问题。
（1）并行认证。RBAC和ABAC同时运行，并包含传统的ABAC策略：
2
2
首先会由RBAC尝试对请求进行鉴权，如果得到的结果是拒绝，就轮到ABAC生效。这样，所有应用只要满足RBAC或ABAC之一即可工作。
使用5或者更详细的日志级别（–v=5或–vmodule=rbac*=5），则可以在API Server日志中看到RBAC的拒绝行为（前缀：RBAC DENY）。可以利用这一信息来确定需要授予何种权限给用户、组或Service Account。等到集群管理员按照RBAC的方式对相关组件进行了授权，并且在日志中不再出现RBAC的拒绝信息，就可以移除ABAC认证方式了。
（2）粗放管理。可以使用RBAC的角色绑定，复制一个粗放的策略。
警告：下面的策略让所有Service Account都具备了集群管理员权限，所有容器运行的应用都会自动接收Service Account的认证，能够对任何API做任何事情，包括查看secret和修改授权。注意，这不是一个值得推荐的策略。
2
3
4
5
6
2--clusterrole=cluster-admin \
3--user=admin \
4--user-kubelet \
5--group=system:serviceaccounts
6
小结：
本节内容较多，但是很重要，希望大家可以好好看，一定要掌握哦。
