Kubernetes的RBAC是啥

  • 2019 年 10 月 16 日
  • 筆記

RBAC: Role-Based Access Control，基于角色的权限控制，有以下三种角色

  1. Role：角色，它其实是一组规则，定义了一组API对象的操作权限
  2. Subject：被作用者，可以是人，也可以是机器，也可以是k8s的用户，最常使用的就是ServiceAccoun
  3. RoleBinding：定义了“被作用者”和“角色的绑定关系”
    简单地说，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

VirMach 便宜 VPS

QNews

QNews