[toc] RBAC: Role-Based Access Control，基于角色的权限控制，有如下三种角色nginx

Role：角色，定义了一组API对象的操做权限
Subject：被做用者，能够是人，也能够是机器，也能够是k8s的用户，最常使用的就是ServiceAccoun
RoleBinding：定义了Subject和Role的绑定关系

简单地说，RoleBinding指定ServiceAccount对应的Role，Pod绑定这个ServiceAccount得到挂载的secret访问APIServrer，ApiServer验证相应的权限api

Pod使用RBAC示例

演示pod使用绑定了Roler的ServiceAccount示例spa

1.建立一个ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: cqh

2.建立一个Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: cqh
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

rules定义了权限规则，容许相应namespaces的pod操做get、watch、list 关于权限的全部操做经过verbs字段控制，全部权限以下code

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

这里verbs定义了权限只能操做get、watch、list对象

3.建立RoleBinding文件，为这个ServcieAccount分配权限

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cqh
  namespace: default
subjects:
- kind: ServiceAccount
  name: cqh
  namespace: default
roleRef:
  kind: Role
  name: cqh
  apiGroup: rbac.authorization.k8s.io

subjects定义了被做用者，这里指定了User类型 roleRef指定了使用的Role规则token

RoleBinding必定能够经过两种方式指定用户ci

1.直接绑定用户 subjects的kind指定为ServiceAccount, name为ServiceAccount的名字
```
system:serviceaccount:<ServiceAccount 名字 >
```
2.直接绑定用户组“Group” subjects的kind指定为Group，name为用户组名
```
system:serviceaccounts:<Namespace 名字>
```

4.pod指定servcieAccountName

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: cqh
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
  serviceAccountName: cqh

这个pod运行起来后，就能够看到ServiceAccount的token，被挂载到了容器的/var/run/secrets/kubernetes.io/serviceaccount目录下get

root@cqh:/# ls -l /var/run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx 1 root root 13 Oct 16 06:05 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 Oct 16 06:05 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 Oct 16 06:05 token -> ..data/token

容器里的应用，就可使用ca.crt来访问APIServer了，此时它已经可以作GET、WATCH和LIST操做，因这cqh这个sa已经被绑定的Role作了限制这个secret是ServiceAccount用来跟APIServer进行交互的受权文件，咱们通常称为token，内容通常是证书或密码，以secret对象的方式保存在etcd中若是一个pod没有指定serviceAccountName，k8s会自动在Namespace下建立一个default的默认SericeAccount分配给这个Pod，这种状况的ServiceAccount没有关联，此时它有访问APIServre的绝大多数权限，这个访问的token，是默认ServiceAccount对应的Secret对象提供的kubernetes

如下是全部对象查看示例权限控制

# kubectl get role
NAME AGE
cqh 51m
# kubectl get sa
NAME SECRETS AGE
cqh 1 54m
default 1 39d
# kubectl get rolebinding
NAME AGE
cqh 49m
# kubectl get po
NAME READY STATUS RESTARTS AGE
cqh 1/1 Running 0 48m
...
# kubectl get clusterrole
NAME AGE
admin 39d
cluster-admin 39d
edit 39d
flannel 39d
...
# kubectl get clusterrolebinding
NAME AGE
cluster-admin 39d
flannel 39d

关于ClusterRole和ClusterRoleBindding

Role和RoleBindding对象都是Namepsace对象，若是要绑定全部的Namespace，须要使用ClusterRole和ClusterRoleBindding，和Role和RoleBinding的区别就是没有Namespace k8s已经内置了不少个为系统保留的ClusterRole，名字都以system：开头

kubectl get clusterrole