Kubernetes的RBAC是啥

RBAC: Role-Based Access Control，基於角色的權限控制，有如下三種角色

1. Role：角色，定義了一組API對象的操做權限
2. Subject：被做用者，能夠是人，也能夠是機器，也能夠是k8s的用戶，最常使用的就是ServiceAccoun
3. RoleBinding：定義了Subject和Role的綁定關係

簡單地說，RoleBinding指定ServiceAccount對應的Role，Pod綁定這個ServiceAccount得到掛載的secret訪問APIServrer，ApiServer驗證相應的權限

Pod使用RBAC示例

演示pod使用綁定了Roler的ServiceAccount示例

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字段控制，全部權限以下

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規則

RoleBinding必定能夠經過兩種方式指定用戶

• 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目錄下

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對象提供的

如下是全部對象查看示例

# 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

k8s提供了4個預約義好的ClusterRole給用戶使用，分別是cluster-admin、admin、edit、view