Kubernetes的RBAC是啥

目錄

• Pod使用RBAC示例
  • 1.創建一個ServiceAccount
  • 2.創建一個Role
  • 3.創建RoleBinding文件，為這個ServcieAccount分配權限
  • 4.pod指定servcieAccountName
• 關於ClusterRole和ClusterRoleBindding

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