RBAC，一个用户可以有多个角色，一个角色可以有多个控制。
在K8S中，有（省略了部分配置）：
1
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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ingress-nginx
rules:
# 对namespaces资源的控制
- apiGroups:
- ''
resources:
- namespaces
verbs:
- get
# 对configmaps、pods、secrets、endpoints资源的配置
- apiGroups:
- ''
resources:
- configmaps
- pods
- secrets
- endpoints
verbs:
- get
- list
- watch
---
# 类似用户角色关联表，但是它是角色到用户一对多，而传统的是用户到角色一对多
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
# 关联的角色（角色Id）
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx
# 绑定到的用户（用户Id）
subjects:
- kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
|
假如我现在有一个需求，我需要为一个用户配置多个角色，在传统的方案中我会怎么做，我会在用户角色关联表里插入多条记录；在K8S的方案中，我需要怎么做呢？我需要创建多个RoleBinding，这个显然不是很优雅的解决方案，不如专门创建一个角色，然后绑定到这个用户上。
现在我发现很多时候，Service、Role、ClusterRole、RoleBinding、ClusterBinding都是谁需要谁自己准备好清单文件，然后由集群管理员创建出来，假如一个恶意的服务，它完全可以准备一份拥有非常高权限的清单文件，然后获取集群的信息，做一些攻击行为，我不知道这种事情现在该如何避免。
其实这个问题时普遍存在的，比如我们手机APP，它就是知道自己要哪些权限，然后申请这些权限，我们再赋予给它。假如我们赋权时不仔细甄别，可能就被APP拿去很高的权限，然后做一些攻击行为了。