Kubernetes的RBAC是啥
发布日期:2021-05-09 01:16:02 浏览次数:14 分类:博客文章

本文共 2791 字,大约阅读时间需要 9 分钟。

目录
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: v1kind: ServiceAccountmetadata:  namespace: default  name: cqh

2.创建一个Role

kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata:  namespace: default  name: cqhrules:- 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: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: cqh  namespace: defaultsubjects:- kind: ServiceAccount  name: cqh  namespace: defaultroleRef:  kind: Role  name: cqh  apiGroup: rbac.authorization.k8s.io

subjects定义了被作用者,这里指定了User类型

roleRef指定了使用的Role规则

RoleBinding一定可以通过两种方式指定用户

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

4.pod指定servcieAccountName

apiVersion: v1kind: Podmetadata:  namespace: default  name: cqhspec:  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 0lrwxrwxrwx 1 root root 13 Oct 16 06:05 ca.crt -> ..data/ca.crtlrwxrwxrwx 1 root root 16 Oct 16 06:05 namespace -> ..data/namespacelrwxrwxrwx 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 roleNAME AGEcqh 51m# kubectl get saNAME SECRETS AGEcqh 1 54mdefault 1 39d# kubectl get rolebindingNAME AGEcqh 49m# kubectl get poNAME READY STATUS RESTARTS AGEcqh 1/1 Running 0 48m...# kubectl get clusterroleNAME AGEadmin 39dcluster-admin 39dedit 39dflannel 39d...# kubectl get clusterrolebindingNAME AGEcluster-admin 39dflannel 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

上一篇:宿主机的容器是如何通过docker0通信的?
下一篇:《高效学习的七个习惯》总结

发表评论

最新留言

路过,博主的博客真漂亮。。
[***.116.15.85]2025年05月04日 13时45分09秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章