

Kubernetes RBAC角色权限控制

开发运维devops

2025-11-24

导读：Kubernetes RBAC角色权限控制

Kubernetes RBAC角色权限控制

在Kubernetes中所有的API对象都保存在ETCD里，可是，对这些API对象的操作，却一定是通过访问kube-apiserver实现的。我们需要APIServer来帮助我们授权工作，而在Kubernetes项目中，负责完成授权(Authorization)的工作机制就是RBAC: 基于角色的访问控制 (Role-Based Access Control)

RBAC是基于角色的访问控制 (Role-Based Access Control) 在RBAC中，权限与角色相关联。Kubernetes 基于角色的访问控制使用rbac.authorization.k8s.io API组来实现权限控制，RBAC允许管理员通过Kubernetes API动态的配置权限策略。如果需要开启RBAC授权需要在apiserver组件中指定--authorization-mode=Node,RBAC

修改完毕后需要重启apiserver，在我提供的二进制安装已经将下面参数添加进去。如果使用的是kubeadm安装在1.6版本默认已经启用了RBAC

这里我们需要明确三个RBAC最基本的概念

·Role: 角色，它定义了一组规则，定义了一组对Kubernetes API对象的操作权限

·Subject: 被作用者，既可以是"人"，也可以是机器，当然也可以是我们Kubernetes中定义的用户(ServiceAccount主要负责kubernetes内置用户)

·RoleBinding: 定义了"被作用者"和"角色"的绑定关系

RBAC API对象

Kubernetes有一个很基本的特性就是它的所有资源都是模型化的API对象，允许执行CRUD(Create、Read、Update、Delete)操作。资源如下

·Pods

·ConfigMaps

·Deployments

·Nodes

·Secrets

·Namespaces

资源对象可能存在的操作有如下

·create

·get

·delete

·list

·update

·edit

·watch

·exec

这些资源和API Group进行关联，比如Pods属于Core API Group，而Deployment属于apps API Group，要在kubernetes中进行RBAC授权

Role && Rolebinding

实际上，Role本身就是一个Kubernetes的API对象，定义文件如下

kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata:  namespace: mynamespace  name: example-rolerules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "watch", "list"]

首先，Role对象指定了它能产生作用的Namespace(mynamespace)。Namespace是kubernetes项目中的一个逻辑管理单位。不同Namespace的API对象，在通过kubectl命令进行操作的时候，是互相隔离的

namespace并不会提供任何实际的隔离或者多租户能力，如果没有设置namespace默认则是default

rules字段定义它的是权限规则，这条规则的含义就是允许"被作用者"，对namespace下面pod (resources中定义)有哪些权限

用户的权限对应的API资源对象已经创建了，但是还没有绑定。也就是只有一个规则没有规定哪些用户使用这个权限

这里进行Rolebinding介绍

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: example-rolebinding  namespace: mynamespacesubjects:- kind: User  name: example-user  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: Role  name: example-role  apiGroup: rbac.authorization.k8s.io

在Rolebinding中定义了一个subject字段，即"被作用者"。它的类型是User，即Kubernetes里的用户，名称为example-user

在kubernetes里的User，也就是用户，只是一个授权系统里的逻辑概念。它需要通过外部认证服务，比如Keystone，来提供。或者直接给APIServer指定一个用户名、密码文件。那么kubernetes的授权系统就能够从这个文件里找到对象的用户

Rolebinding对象通过roleRef字段可以直接通过名字，来引用前面定义的Role对象(example-role)，从而定义了"被作用者(Subject)"和"角色(Role)"之间的绑定关系

Role和RoleBinding 他们的权限限制规则仅仅在他们自己的namespace内有效，roleRef也只能引用当前namespace里的Role对象

ClusterRole && ClusterRoleBinding

对于某一个role想要作用的namespace的时候，就必须需要使用ClusterRole和ClusterRoleBinding两个组合。这两个API 对象的用法跟Role和Rolebinding完全一样

kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: example-clusterrolerules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "watch", "list"] ###############################################kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: example-clusterrolebindingsubjects:- kind: User  name: example-user  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: ClusterRole  name: example-clusterrole  apiGroup: rbac.authorization.k8s.io

在上面的例子中，ClusterRole和ClusterRoleBinding的组合，意味着名叫example-user的用户，拥有对所有namespace里的Pod进行Get、Watch、List操作的权限。

类似的，Role对象的rules字段也可以进一步细化，可以只针对某一个具体权限对象进行设置

rules:- apiGroups: [""]  resources: ["configmaps"]  resourceNames: ["my-config"]  verbs: ["get"]

上面的例子表示，这条规则的"被作用者"，只对my-config的configmap对象有权限进行get操作

前面也说过，在Kubernetes中已经内置了很多个位系统保留的ClusterRole，它们的名字都是以system:开头。一般来说，这些内置的ClusterRole，是绑定给Kubernetes系统组件对应的ServiceAccount使用

#我们可以通过下面的命令获取到[root@abcdocker sa-test]# kubectl get clusterrolesNAME                                                                   AGEadmin                                                                  93dapprove-node-server-renewal-csr                                        93dcluster-admin                                                          93dedit                                                                   93d...system:public-info-viewer                                              93dsystem:volume-scheduler                                                93dtraefik-ingress-controller                                             45d

此外，Kubernetes还提供了四个预先定义好的ClusterRole来提供用户直接使用

·cluster-admin

·admin

·edit

·view

其中cluster-admin角色，对应的是整个Kubernetes项目中最高权限(verbs=*)

#我们可以通过下面的命令查看clusterrole的权限[root@abcdocker sa-test]# kubectl describe clusterrole cluster-admin -n kube-systemName:         cluster-adminLabels:       kubernetes.io/bootstrapping=rbac-defaultsAnnotations:  rbac.authorization.kubernetes.io/autoupdate: truePolicyRule:  Resources  Non-Resource URLs  Resource Names  Verbs  ---------  -----------------  --------------  -----  *.*        []                 []              [*]             [*]                []              [*]

ServiceAccount

前面所介绍的大多数不使用，ServiceAccount主要负责kubernetes内置用户，下面简单定义一个ServiceAccount

apiVersion: v1kind: ServiceAccountmetadata:  namespace: mynamespace  name: example-sa

我们定义了一个serverAccount对象，只需要name以及namespace最基础字段就可以。然后通过编写rolebinding的yaml文件，来为这个serviceAccount分配权限

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: example-rolebinding  namespace: mynamespacesubjects:- kind: ServiceAccount  name: example-sa  namespace: mynamespaceroleRef:  kind: Role  name: example-role  apiGroup: rbac.authorization.k8s.io

在Rolebinding对象里，subject字段的类型(kind)，不在是一个User，而是一个名叫example-sa的ServerAccount。而roleRef引用的Role对象，依然名叫example-role。也就是我们上面定义的

接下来我们创建演示

#yaml文件如下[root@abcdocker serveraccount]# cat pod-sa.yamlapiVersion: v1kind: Podmetadata:  namespace: mynamespace  name: sa-token-testspec:  containers:  - name: nginx    image: nginx:1.7.9  serviceAccountName: example-sa
[root@abcdocker serveraccount]# cat role.yamlkind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata:  namespace: mynamespace  name: example-rolerules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "watch", "list"]  [root@abcdocker serveraccount]# cat role-binding.yamlkind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: example-rolebinding  namespace: mynamespacesubjects:- kind: ServiceAccount  name: example-sa  namespace: mynamespaceroleRef:  kind: Role  name: example-role  apiGroup: rbac.authorization.k8s.io  #接下来我们创建命名空间[root@abcdocker serveraccount]# kubectl create namespace mynamespacenamespace/mynamespace created[root@abcdocker serveraccount]# kubectl apply -f .rolebinding.rbac.authorization.k8s.io/example-rolebinding createdrole.rbac.authorization.k8s.io/example-role createdserviceaccount/example-sa created [root@abcdocker serveraccount]# kubectl get sa  -n mynamespaceNAME         SECRETS   AGEdefault      1         26sexample-sa   1         22s [root@abcdocker serveraccount]# kubectl get sa -n mynamespace example-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata:  annotations:    kubectl.kubernetes.io/last-applied-configuration: |      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-sa","namespace":"mynamespace"}}  creationTimestamp: "2019-11-28T08:01:22Z"  name: example-sa  namespace: mynamespace  resourceVersion: "14579937"  selfLink: /api/v1/namespaces/mynamespace/serviceaccounts/example-sa  uid: 4481a40f-11b5-11ea-a57e-525400d7b284secrets:- name: example-sa-token-wms94

Kubernetes会为ServiceAccount自动创建一个Secret对象，即ServiceAccount定义最下面的secrets字段。其中，这里的secret就是ServiceAccount对应来跟APIServer进行交互的授权文档，一般为token，保存证书和密码等，它以一个Secret对象保存在ETCD中

这时候我们就可以直接引用这个sa(serviceAccount)了

apiVersion: v1kind: Podmetadata:  namespace: mynamespace  name: sa-token-testspec:  containers:  - name: nginx    image: nginx  serviceAccountName: example-sa  #在最下面一行我们定义了一个名为example-sa

接下来我们可以通过describe查看pod状态

[root@abcdocker serveraccount]# kubectl describe pod -n mynamespace sa-token-testName:               sa-token-testNamespace:          mynamespace...    Mounts:      /var/run/secrets/kubernetes.io/serviceaccount from example-sa-token-wms94 (ro)...

ServiceAccount的token也就是secret对象是被Kubernetes自动挂载到了容器/var/run/secrets/kubernetes.io/serviceaccount目录下

我们可以到Pod目录进行查看

kubectl exec -it sa-token-test -n mynamespace -- /bin/bashroot@sa-token-test:/# ls /var/run/secrets/kubernetes.io/serviceaccountca.crt namespace  token

在Kubernetes集群访问主要是通过ca.crt来访问Apiserver，更重要的是此时它只可以做GET、WATCH和LIST操作。因为example-sa这个ServiceAccount的权限已经被我们绑定了role限制

如果一个Pod没有声明sa，Kubernetes会自动在它的namespace创建一个名称为default的默认ServiceAccount，然后分配给Pod。但是这种情况下默认ServiceAccount没有关联任何Role。也就是说它有APIServer的绝大多数权限

User && Group

Kubernetes除了有用户(User)，还拥有用户组(Group)概念，如果我们Kubernetes配置了外部认证服务的话，这个用户组的概念就由外部认证服务提供

一个ServiceAccount在Kubernetes对应的用户的名字是

system:serviceaccount:<ServiceAccount名字>

而对应的用户组则是

system:serviceaccounts:<Namespace名字>

比如，我们可以在RoleBinding中定义如下subjects

subjects:- kind: Group  name: system:serviceaccounts:mynamespace  apiGroup: rbac.authorization.k8s.io #这就意味着role的规则权限，作用于mynamespace里的所有ServiceAccount，这就用到了用户组的概念   subjects:- kind: Group  name: system:serviceaccounts  apiGroup: rbac.authorization.k8s.io #这个role的规则权限，则作用于整个系统里ServiceAccount

在Kubernetes中已经内置了很多个为系统保留的ClusterRole，它们的名字都以system:开头，可以使用kubectl get clusterroles查找到

现在我们可以理解，所谓的角色(Role)，其实就是一组规则权限列表，而我们分配这些权限的方式，就是通过创建RoleBinding对象，将被用者(subject)和权限列表绑定。

而对应的ClusterRole和ClusterRoleBinding，则是Kubernetes集群级别的Role和RoleBinding，它们不受namespace限制

一、创建一个只能访问某个namespace的ServiceAccount

当我们创建一个sa之后，会自动帮我们创建一个secrets

[root@abcdocker ~]# kubectl create sa test-sa -n kube-systemserviceaccount/test-sa created

接下来可以查看一下sa

[root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata:  creationTimestamp: "2019-11-28T09:32:54Z"  name: test-sa  namespace: kube-system  resourceVersion: "14590921"  selfLink: /api/v1/namespaces/kube-system/serviceaccounts/test-sa  uid: 0e218ad3-11c2-11ea-a57e-525400d7b284secrets:- name: test-sa-token-fs4fx

可以通过get secret查看

[root@abcdocker ~]# kubectl get secrets -n kube-system |grep test-sa-tokentest-sa-token-fs4fx                              kubernetes.io/service-account-token   3      17h

我们需要创建一个role (角色)对象与sa进行关联

#yaml文件如下cat >>sa-role.yaml<<EOFapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: sa-role  namespace: kube-systemrules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "list"]- apiGroups: ["apps", "extensions"]  resources: ["pods", "deployment", "replicasets"]  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]EOF#这里我们创建的role设置的权限是对pod有get和list权限，对deployment有下面其他权限  #执行文件yaml[root@abcdocker ~]# kubectl apply -f  sa-role.yamlrole.rbac.authorization.k8s.io/sa-role created #检查状态[root@abcdocker ~]# kubectl get role -n kube-systemNAME                                             AGEextension-apiserver-authentication-reader        93dprometheus-k8s                                   15dsa-role                                          9s...#我们刚刚在kube-sytem下创建一个名称为sa-role的role

角色创建完成之后我们就需要创建一个RoleBinding

cat >>sa-rolebinding.yaml<<EOFapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: sa-rolebinding  namespace: kube-systemsubjects:- kind: ServiceAccount  name: test-sa  namespace: kube-systemroleRef:  kind: Role  name: sa-role  apiGroup: rbac.authorization.k8s.ioEOF #执行 [root@abcdocker ~]# kubectl apply -f sa-rolebinding.yamlrolebinding.rbac.authorization.k8s.io/sa-rolebinding created [root@abcdocker ~]# kubectl get rolebinding -n kube-system|grep sasa-rolebinding                                      28s

这时候我们创建的ServerAccount已经和我们role进行绑定了，通过rolebinding进行绑定。下面可以进行测试

#首先我们复制我们创建sa中secret里面的token

[root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata:  creationTimestamp: "2019-11-28T09:32:54Z"  name: test-sa  namespace: kube-system...secrets:- name: test-sa-token-fs4fx#这个name为我们secret名称，创建sa的时候会自动给我们创建secret  #接下来我们查看这个secret中的token[root@abcdocker ~]# kubectl get secrets test-sa-token-fs4fx -n kube-system -o yamlapiVersion: v1data:...  namespace: a3ViZS1zeXN0ZW0=  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUowWlhOMExYTmhMWFJ2YTJWdUxXWnpOR1o0SWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWJtRnRaU0k2SW5SbGMzUXRjMkVpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1MWFXUWlPaUl3WlRJeE9HRmtNeTB4TVdNeUxURXhaV0V0WVRVM1pTMDFNalUwTURCa04ySXlPRFFpTENKemRXSWlPaUp6ZVhOMFpXMDZjMlZ5ZG1salpXRmpZMjkxYm5RNmEzVmlaUzF6ZVhOMFpXMDZkR1Z6ZEMxellTSjkuU04yRm0wemdiUi1XU21oVTdOYkxMWDZFRVNiSnNpNDNWRHZpOXJUdG1UcDVzSXl0RzJKNkFqUGNBeGxqSHE1dkdqVWNTTGpoOXd2aDBSV25HMXUydzZ3MHUtTGd0S0g3NllZNWVHRGVtSUxJaTcxeDZDNXlrTE85a3hNVU1sOG9WQmxnVGhFRVVrZEJjRk96X3pveEZCc1lGRV9xcm1NSGNma29RU0Y3UGRWSnp0VjBuYkZmem9fdWJ4cU5Zd2RaYzJIc2wyZ1VOT3NzcGRVdlV2ZXd6WGIwZzJwZnJ4NlVuUkpWU1FoSjJWbjdBWlFrXzJ6c0p2SXJPeXNLSlpJSm5RRlZFUGJCSXhIazNaR2o4WExjRUVEcmMySWRHUDNLcGFwdHlkU21hXzdXS1lmMFlQSThkdmZvZmdJcTlyUFd4YjRqeEg0NFFUZ0xtS1lHZ0VxR2x3...

这里我们复制token，使用bease64进行解密

echo "xxx" |base64 -d

现在token已经创建好了，我们使用dashboard进行演示

接下来我们打开dashboard的地址，将解密后的token复制进去

我们登陆到dashboard界面上，默认访问的为default命名空间，因为我们授权的是kube-system空间，所以很多地方没有权限。会有下面的报错

在我们配置role的yaml文件中，只分配了pod和deployment以及replicasets相关权限，像pvc这种并没有分配所以会提示firidden

我们将default修改为kube-system即可

我们还可以直接通过rolebinding绑定系统提供的role权限

二、创建一个可以访问所有namespace的ServiceAccount

上面创建单个namespace访问权限主要是用了role和rolebinding，接下来我们使用clusterRole和ClusterRoleBinding进行演示。使用role和rolebinding只会绑定特定的namespace下，clusterRole会绑定到集群下

首先我们创建一个ServiceAccount对象

#这次我们不使用kubectl命令行创建，采用yaml的方式，关于sa的yaml定义格式可以参考上面的sa的介绍，并且我们将所有的配置文件写在一个yaml中 cat >>sa.yaml<<EOFapiVersion: v1kind: ServiceAccountmetadata:  name: abcdocker-sa  namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: abcdocker-clusterrolebinding   #clusterrolebinding的名称subjects:      #被作用者- kind: ServiceAccount    #类型  name: abcdocker-sa      #sa名称  namespace: kube-system  #sa命名空间roleRef:     #角色引用  kind: ClusterRole   #类型为clusterRole  name: cluster-admin   #clust-admin为rbac系统最大权限  apiGroup: rbac.authorization.k8s.io#这里的clusterRole我们直接使用系统内置的变量，我们直接创建clusterrolebinding就可以了EOF  #接下来开始创建[root@abcdocker sa-test]# kubectl apply -f  sa.yamlserviceaccount/abcdocker-sa createdclusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding created #这里我们可以看到sa和clusterrolebinding已经被创建

我们可以过滤到sa和clusterrolebinding

[root@abcdocker sa-test]# kubectl get sa,clusterrolebinding -n kube-system|grep abcdockerserviceaccount/abcdocker-sa                         1         7m50s clusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding                           7m50s

接下来我们验证还是使用创建的sa中的secret token进行访问dashboard，查看对应权限是否正常

[root@abcdocker sa-test]# kubectl describe sa -n kube-system abcdocker-saName:                abcdocker-saNamespace:           kube-systemLabels:              Annotations:         kubectl.kubernetes.io/last-applied-configuration:                       {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"abcdocker-sa","namespace":"kube-system"}}Image pull secrets:  Mountable secrets:   abcdocker-sa-token-qkb7cTokens:              abcdocker-sa-token-qkb7cEvents:              [root@abcdocker sa-test]# kubectl get secrets -n kube-system abcdocker-sa-token-qkb7c -o yamlapiVersion: v1data:...  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUpoWW1Oa2IyTnJaWEl0YzJFdGRHOXJaVzR0Y1d0aU4yTWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lZV0pqWkc5amEyVnlMWE5oSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWRXbGtJam9pTW1VMVpXRmpOV1F0TVRJNE9DMHhNV1ZoTFdFMU4yVXROVEkxTkRBd1pEZGlNamcwSWl3aWMzVmlJam9pYzNsemRHVnRPbk5sY25acFkyVmhZMk52ZFc1ME9tdDFZbVV0YzNsemRHVnRPbUZpWTJSdlkydGxjaTF6WVNKOS5uQlpIc0c5Yjhfa1ExcktDVFoyVDRlVjYzWGFsNnJ5TnRuOHBIODNEYnJSTTJMZEdwWThfa1hVWWYxd1dUMHFVTk1oVUZhZ2FaNXc2cmpwM2pwVkhwZEVCYnM2akhCRTJzY0tJYXZHMFVlQUtfaWl6TDRDWU8xakMwa0pxWk5YcmhWdWVfb0xsY0NLVTNCRHZ0QWVSS2tTbWZJdGpLZU5VT1pSZWlPT05KMzJIcmNpdUdDZ2xkWXpXSXp5OFd1dElXaGRoRVRHUjRNY2FZUVB0eWR5Sjk5bU5fMGk1NVdKQmI0a1VjbFBZeERmWlFnMlg0UmFxdl84ZS1ySGtoWnBjQThFVmQwQ0JfZFMyVTRCSjNRN0VqQ2tnOFZvNUkxa1llMFlDMEJxWS1NS2dGekR1QXphblpiTTV5dU9nanBxTG9Gd0s5UHYya0t3Mld5Vjh0NWM1RWc=...