系列文章目录

文章目录

• 系列文章目录
• 前言
• 一、RBAC整体架构图
• 二、RBAC授权规则
• 三、Kubernetes RBAC实践
• • 3.1 实践：User --> Rolebinding --> Role
  • 3.2 实践：User --> ClusterRolebinding --> ClusterRole
  • 3.3 实践：User --> Rolebinding --> Clusterrole
• 总结

---

前言

RBAC（Role-Based Access Control，基于角色的访问控制）是一种新型、灵活且使用广泛的访问控制机制，它将权限授予“角色”(role)之上，这一点有别于传统访问机制中将权限直接赋予使用者的方式。

在RBAC中，用户（User）就是一个可以独立访问计算机系统中的数据或者用数据表示的其他资源的主体（Subject）。角色是指一个组织或任务中的工作或者位置，它代表一种权利、资格和责任。许可（Permission）就是允许对一个或多个客体（Object）执行的操作。一个用户可以经授权而拥有多个角色，一个角色可由多个用户构成；每个角色可拥有多种许可，每个许可也可授权给多个不同的角色。每个操作可施加于多个客体（受控对象），每个客体也可以接受多个操作。

小结：RBAC简单来说就是让一个用户（Users）扮演一个角色（Role），角色拥有权限，让用户绑定该角色；随后在授权机制中，只需要将权限授权给某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。

一、RBAC整体架构图

RBAC（Role Based Access Control）：基于角色访问控制授权。
允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。

RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。
RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

RBAC的三个基本概念：
Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount
Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
RoleBinding：定义了“被作用者”和“角色”的绑定关系。

Role 和 ClusterRole
Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。
ClusterRole 跟 Role 类似，但是可以在集群中全局使用。

[root@m ~]# kubectl get rolebinding -o wide -A
NAMESPACE NAME ROLE AGE USERS GROUPS SERVICEACCOUNTS
命名空间 binding绑定名称 角色 binding已存活时间 用户(三种user之一) 用户组(三种user之一) 服务账号(三种user之一)

[root@m ~]# kubectl get clusterrolebinding -o wide -A
NAME ROLE AGE USERS GROUPS SERVICEACCOUNTS
binding绑定名称 角色 binding已存活时间 用户(三种user之一) 用户组(三种user之一) 服务账号(三种user之一)

因为user有三种，所以使用 get binding 命令，后面三列都是表示user的 USERS GROUPS SERVICEACCOUNTS

rbac 一头是role，用来提供权限；一头是user，包括三种，其中 user/userGroup 用来构成了 userAccount 用户账号体系，serviceAccount 用来构成了 serviceAccount 账号体系，所以，学rbac就离不开 userAccount 和 serviceAccount。
另外注意，在这个过程中，属于 kind 类资源的 role clusterRole rolebinding clusterRoleBinding serviceAccount
user和userGroup并不属于 kind 类资源

二、RBAC授权规则

RBAC授权规则是通过四种资源来进行配置的，他们可以分为两个组：

(1) Role（角色）和ClusterRole（集群角色），它们指定了在资源上可以执行哪些动作。
(2) RoleBinding（角色绑定）和ClusterRoleBinding（集群角色绑定），它们将上述角色绑定到特定的用户、组或ServiceAccounts上。

角色定义了可以做什么操作，而绑定定义了谁可以做这些操作，如下图所示：

绑定关系：

角色和集群角色，或者角色绑定和集群角色绑定之间的区别在于角色和角色绑定是名称空间级别，而集群角色和集群角色绑定是集群级别的资源。

(1) RoleBind–Role：在kubernetes授权机制中，采用RBAC的方式进行授权，把对象的操作权限定义到一个角色当中，而将用户绑定到该角色，从而使得用户得到对应角色的权限。比如下图，当用户（User1）绑定到Role角色当中，User1就获取了对应的NamespaceA的操作权限，但是对于NamespaceB是没有权限进行操作的。如get，list等操作。

(2) ClusterRoleBind–ClusterRole：集群级别的授权，定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，如下图(只看蓝色的线连接)，当用户（User1）通过ClusterRolebinding到ClusterRole，从而User1遍拥有了集群的操作权限。

(3) RoleBind-ClusterRole：这种方式进行绑定时，用户仅能获取当前名称空间的所有权限。为什么这么绕呢？？ 举例有10个名称空间，每个名称空间都需要一个管理员，而每个管理员的权限是一致的。那么此时需要去定义这样的管理员，使用RoleBinding就需要创建10个Role，这样显得更加繁重。为了当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操作权限，也就是此时只需要创建一个ClusterRole就解决了以上的需求。比如下图中的User2和User3用户虽然绑定了ClusterRole，但是他们也只有自己的名称空间NamespaceB中权限。

三、Kubernetes RBAC实践

这里由于要切换用户，使用root用户同时不停的在kubernetes-admin用户和上面创建的kube-user1用户之间进行测试。故这里创建一个测试用户打开另外一个终端进行测试。

[root@k8s-master ~]# useradd ik8s [root@k8s-master ~]# cp -rp .kube/ /home/ik8s/ [root@k8s-master ~]# chown -R ik8s.ik8s /home/ik8s/ [root@k8s-master ~]# su - ik8s [ik8s@k8s-master ~]$ kubectl config use-context kube-user1@kubernetes Switched to context "kube-user1@kubernetes". [ik8s@k8s-master ~]$ kubectl config view ...... current-context: kube-user1@kubernetes #这里可以看到当前已经切换到kube-user1用户了 ...... [ik8s@k8s-master ~]$ kubectl get pods #测试kube-user1用户的权限，可以看出目前它没有任何权限 Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"

3.1 实践：User --> Rolebinding --> Role

1）角色（Role）创建。（说明：一个Role对象只能用于授予对某一单一名称空间中资源的访问权限）

[root@k8s-master ~]# kubectl create role -h #查看role创建帮助 ...... Usage:kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run] [options] --verb #指定权限 --resource #指定资源或者资源组 --dry-run #干跑模式并不会创建[root@k8s-master ~]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑模式查看role的定义格式 apiVersion: rbac.authorization.k8s.io/v1 kind: Role #资源类型 metadata:creationTimestamp: nullname: pods-reader #资源名称 rules: - apiGroups: #定义对哪些api组内的资源可以进行操作- ""resources: #定义对哪些资源可以进行操作- podsverbs: #定义操作的权限- get- list- watch[root@k8s-master ~]# cd manfests/ [root@k8s-master manfests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > role-demo.yaml[root@k8s-master manfests]# vim role-demo.yaml #编写资源清单文件 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:name: pods-readernamespace: default rules: - apiGroups:- ""resources:- podsverbs:- get- list- watch [root@k8s-master manfests]# kubectl apply -f role-demo.yaml role.rbac.authorization.k8s.io/pods-reader created [root@k8s-master manfests]# kubectl get role NAME AGE pods-reader 4s [root@k8s-master manfests]# kubectl describe role/pods-reader Name: pods-reader Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pods-reader","namespace":"default"},"rules... PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----pods [] [] [get list watch] #这里表示当前定义了pods-reader这个角色对pods资源拥有get、list、watch的权限。

2）角色的绑定。（RoleBinding可以引用在同一名称空间定义的Role对象）

[root@k8s-master manfests]# kubectl create rolebinding -h #查看rolebinding创建帮助 ...... Usage:kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options] --role #指定role的名字 --user #指定哪个用户[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --role=pods-reader --user=kube-user1 --dry-run -o yaml #干跑模式查看rolebinding的定义格式 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding #资源类型 metadata:creationTimestamp: nullname: kube-user1-read-pods #资源名称 roleRef: #指定roleapiGroup: rbac.authorization.k8s.iokind: Rolename: pods-reader subjects: #指定user - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --role=pods-reader --user=kube-user1 --dry-run -o yaml > rolebinding-demo.yaml [root@k8s-master manfests]# vim rolebinding-demo.yaml #编辑资源清单文件 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:name: kube-user1-read-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: pods-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl apply -f rolebinding-demo.yaml rolebinding.rbac.authorization.k8s.io/kube-user1-read-pods created [root@k8s-master manfests]# kubectl get rolebinding NAME AGE kube-user1-read-pods 9s [root@k8s-master manfests]# kubectl describe rolebinding kube-user1-read-pods #查看角色绑定的信息，这里可以看到user kube-user1绑定到了pods-reader这个角色上。 Name: kube-user1-read-pods Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-pods","namespace":"... Role:Kind: RoleName: pods-reader Subjects:Kind Name Namespace---- ---- ---------User kube-user1

3）权限测试

这时候我们使用kube-user1用户进行测试

[ik8s@k8s-master ~]$ kubectl config use-context kube-user1@kubernetes #如果没有切换到该kube-user1用户，通过kubectl config use-context进行切换[ik8s@k8s-master ~]$ kubectl get pods #在default名称空间获取pods信息 NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 3d nginx-statefulset-1 1/1 Running 0 3d nginx-statefulset-2 1/1 Running 0 3d nginx-statefulset-3 1/1 Running 0 3d pod-sa-demo 1/1 Running 0 27h[ik8s@k8s-master ~]$ kubectl get pods -n kube-system #测试获取kube-system名称空间中的pods Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "kube-system"

从上面的操作可以看出，role的定义和绑定，仅作用于当前名称空间，在获取别的名称空间比如kube-system名称空间时，一样会出现Forbidden。

3.2 实践：User --> ClusterRolebinding --> ClusterRole

1）ClusterRole定义

ClusterRole资源对象可以授予与Role资源对象相同的权限，但由于它们属于集群范围的对象，也可以使用它们授予对以下几种资源的访问权限：

a. 集群范围资源（例如节点，即Node）
b. 非资源类型endpoint（例如/api、/healthz等。）
c. 跨所有名称空间的名称空间资源（例如pod，运行kubectl get pods --all-namespaces来查询集群中所有的pod）

[root@k8s-master manfests]# kubectl create clusterrole -h #查看clusterrole创建帮助 ...... Usage:kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run] [options] --verb #指定权限 --resource #指定资源或者资源组[root@k8s-master manfests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑模式查看clusterrole的定义格式 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:creationTimestamp: nullname: cluster-reader rules: - apiGroups:- ""resources:- podsverbs:- get- list- watch[root@k8s-master manfests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > clusterrole-demo.yaml [root@k8s-master manfests]# vim clusterrole-demo.yaml #编辑资源清单 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:name: cluster-reader rules: - apiGroups:- ""resources:- podsverbs:- get- list- watch[root@k8s-master manfests]# kubectl apply -f clusterrole-demo.yaml #创建clusterrole clusterrole.rbac.authorization.k8s.io/cluster-reader created [root@k8s-master manfests]# kubectl get clusterrole |grep "cluster-reader" cluster-reader 19s [root@k8s-master manfests]# kubectl describe clusterrole/cluster-reader Name: cluster-reader Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"name":"cluster-reader"},"rules":[{"apiGrou... PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----pods [] [] [get list watch]

2）ClusterRoleBinding定义

#这里还是使用kube-user1用户，所以先将上面的角色绑定信息删除 [root@k8s-master manfests]# kubectl get rolebinding #查看角色绑定信息 NAME AGE kube-user1-read-pods 27m [root@k8s-master manfests]# kubectl delete rolebinding kube-user1-read-pods #删除前面的绑定 rolebinding.rbac.authorization.k8s.io "kube-user1-read-pods" delete [ik8s@k8s-master ~]$ kubectl get pods #删除后再用kube-user1用户获取pods资源信息，就立马出现Forbidden了 Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"[root@k8s-master manfests]# kubectl create clusterrolebinding -h Usage:kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options] --clusterrole #指定clusterrole --user #指定用户[root@k8s-master manfests]# kubectl create clusterrolebinding kube-user1-read-all-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata:creationTimestamp: nullname: kube-user1-read-all-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl create clusterrolebinding kube-user1-read-all-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml > clusterrolebinding-demo.yaml [root@k8s-master manfests]# vim clusterrolebinding-demo.yaml #编辑资源清单文件 cat clusterrolebinding-demo.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata:name: kube-user1-read-all-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl apply -f clusterrolebinding-demo.yaml #创建clusterrolebinding clusterrolebinding.rbac.authorization.k8s.io/kube-user1-read-all-pods created [root@k8s-master manfests]# kubectl get clusterrolebinding/kube-user1-read-all-pods NAME AGE kube-user1-read-all-pods 25s [root@k8s-master manfests]# kubectl describe clusterrolebinding/kube-user1-read-all-pods #查看clusterrolebinding资源kube-user1-read-all-pods详细信息，可以看到kube-user1用户已经绑定到clusterrole资源cluster-reader上了。 Name: kube-user1-read-all-pods Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-all-pod... Role:Kind: ClusterRoleName: cluster-reader Subjects:Kind Name Namespace---- ---- ---------User kube-user1

3）权限测试

[ik8s@k8s-master ~]$ kubectl get pods #角色绑定后再次获取pods信息，已经可以正常查看 NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 3d1h nginx-statefulset-1 1/1 Running 0 3d1h nginx-statefulset-2 1/1 Running 0 3d1h nginx-statefulset-3 1/1 Running 0 3d1h pod-sa-demo 1/1 Running 0 28h[ik8s@k8s-master ~]$ kubectl get pods -n kube-system #切换名称空间也是可以查看的 NAME READY STATUS RESTARTS AGE coredns-bccdc95cf-9gsn8 1/1 Running 0 8d coredns-bccdc95cf-x7m8g 1/1 Running 0 8d etcd-k8s-master 1/1 Running 0 8d kube-apiserver-k8s-master 1/1 Running 0 8d kube-controller-manager-k8s-master 1/1 Running 0 8d kube-flannel-ds-amd64-gg55s 1/1 Running 0 8d kube-flannel-ds-amd64-ssr7j 1/1 Running 5 8d kube-flannel-ds-amd64-w6f9h 1/1 Running 4 8d kube-proxy-77pbc 1/1 Running 3 8d kube-proxy-qs655 1/1 Running 3 8d kube-proxy-xffq4 1/1 Running 0 8d kube-scheduler-k8s-master 1/1 Running 0 8d[ik8s@k8s-master ~]$ kubectl delete pods/pod-sa-demo #在进行删除pod测试时，还是会报Forbidden，这是因为在授权时就没授予delete权限的。 Error from server (Forbidden): pods "pod-sa-demo" is forbidden: User "kube-user1" cannot delete resource "pods" in API group "" in the namespace "default"

从上面的操作可以看出，clusterrole的定义和clusterrolebinding的绑定，可以获取到集群内所有资源的对应权限。

3.3 实践：User --> Rolebinding --> Clusterrole

将用户kube-user1通过角色绑定（RoleBinding）到集群角色cluster-reader当中，此时kube-user1仅作用于当前名称空间的所有pods资源的权限。

1）绑定

#首先删除上面的clusterrolebinding [root@k8s-master manfests]# kubectl delete clusterrolebinding kube-user1-read-all-pods clusterrolebinding.rbac.authorization.k8s.io "kube-user1-read-all-pods" deleted[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:creationTimestamp: nullname: kube-user1-read-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml > rolebinding-clusterrole-demo.yaml [root@k8s-master manfests]# vim rolebinding-clusterrole-demo.yaml #编辑资源清单文件 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:name: kube-user1-read-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl apply -f rolebinding-clusterrole-demo.yaml rolebinding.rbac.authorization.k8s.io/kube-user1-read-pods created [root@k8s-master manfests]# kubectl get rolebinding kube-user1-read-pods NAME AGE kube-user1-read-pods 32s [root@k8s-master manfests]# kubectl describe rolebinding kube-user1-read-pods Name: kube-user1-read-pods Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-pods","namespace":"... Role:Kind: ClusterRoleName: cluster-reader Subjects:Kind Name Namespace---- ---- ---------User kube-user1

2）权限测试

[ik8s@k8s-master ~]$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 3d1h nginx-statefulset-1 1/1 Running 0 3d1h nginx-statefulset-2 1/1 Running 0 3d1h nginx-statefulset-3 1/1 Running 0 3d1h pod-sa-demo 1/1 Running 0 28h[ik8s@k8s-master ~]$ kubectl get pods -n kube-system Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "kube-system"

从上面的操作可以看出，角色绑定（Rolebinding）和集群角色（ClusterRole）绑定后，用户只拥有自己当前名称空间的对应的权限。

---

总结

本文介绍了 默认的ServiceAccount 和 自定义ServiceAccount ，默认的kubeconfig文件和自建证书，rbac 基于角色的访问控制。

工作中，操作k8s的过程中，并不需要程序员去写 role - binding -user 这样的rbac，也不需要修改kubeconfig 文件(user - context - cluster)，也不需要自定义serviceAccount。所以，本文的实践价值在于工作中从网上download下来的yaml文件，如果出现 rbac 的错误，自己知道怎样修改，保证容器化正常部署即可。

天天打码，天天进步！！

总结

以上是生活随笔为你收集整理的Kubernetes_授权认证_RBAC_静态Pod网关apiserver底层的RBAC授权的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。