- Kubernetes的RBAC
- 一、RBAC介绍
- 1.1 角色和集群角色
- 1.2 角色绑定和集群角色绑定
- 1.3 资源
- 1.4 主体
- 二、RBAC实战
- 2.1 创建用户
- 2.2 查看所有用户及context
- 2.3 创建rule
- 2.4 创建 RoleBinding
- 三、验证操作
- 注意点
在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC,启用RABC。在RABC API中,通过如下的步骤进行授权:1)定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;2)绑定角色:将主体与角色进行绑定,对用户进行访问授权。
1.1 角色和集群角色在RBAC API中,角色包含代表权限集合的规则。在这里,权限只有被授予,而没有被拒绝的设置。在Kubernetes中有两类角色,即普通角色和集群角色。可以通过Role定义在一个命名空间中的角色,或者可以使用ClusterRole定义集群范围的角色。一个角色只能被用来授予访问单一命令空间中的资源。
集群角色(ClusterRole)能够被授予如下资源的权限:
集群范围的资源(类似于Node)
非资源端点(类似于”/healthz”)
集群中所有命名空间的资源(类似Pod)
角色绑定用于将角色与一个或一组用户进行绑定,从而实现将对用户进行授权的目的。主体分为用户、组和服务帐户。角色绑定也分为角色普通角色绑定和集群角色绑定。角色绑定只能引用同一个命名空间下的角色。
角色绑定也可以通过引用集群角色授予访问权限,当主体对资源的访问仅限与本命名空间,这就允许管理员定义整个集群的公共角色集合,然后在多个命名空间中进行复用。
集群角色可以被用来在集群层面和整个命名空间进行授权
在Kubernets中,主要的资源包括:Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMaps等。另外,有些资源下面存在子资源,例如:Pod下就存在log子资源
1.4 主体RBAC授权中的主体可以是组,用户或者服务帐户。用户通过字符串表示,比如“alice”、 “bob@example.com”等,具体的形式取决于管理员在认证模块中所配置的用户名。system:被保留作为用来Kubernetes系统使用,因此不能作为用户的前缀。组也有认证模块提供,格式与用户类似。
二、RBAC实战 2.1 创建用户(umask 077; openssl genrsa -out baison.key 2048) //创建用户证书key openssl req -new -key baison.key -out baison.csr -subj "/O=group/CN=chenteng" //创建用户证书请求,-subj指定组和用户,其中O是组名,CN是用户名 openssl x509 -req -in baison.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out baison.crt -days 3650 //使用k8s的ca签发用户证书 kubectl config set-credentials chenteng --client-certificate=baison.crt --client-key=baison.key --embed-certs=true //用户配置 kubectl config set-context baison@kubernetes --cluster=kubernetes --user=chenteng //context设置 可以切换到新用户了,但此时用户啥权限都没有 kubectl config use-context chenteng@kubernetes2.2 查看所有用户及context
[root@master ~]# kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
chenteng@kubernetes kubernetes chenteng
* kubernetes-admin@kubernetes kubernetes kubernetes-admin default
[root@master ~]# kubectl config get-users
NAME
chenteng
kubernetes-admin
2.3 创建rule
首先查看一下rule的yaml文件格式
kubectl create role pod-rule --verb=get,list,watch --resource=pods --dry-run -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: pods-reader rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch
使用文件或者命令后查看,rule不受ns限制
[root@master rule]# kubectl get role NAME CREATED AT leader-locking-nfs-provisioner 2021-08-29T11:15:24Z pod-rule 2021-10-02T10:03:51Z2.4 创建 RoleBinding
使用命令创建
[root@master rule]# kubectl create rolebinding pod-rule-binding --role=pod-rule --user=chenteng -n default rolebinding.rbac.authorization.k8s.io/pod-rule-binding created [root@master rule]# kubectl get rolebinding NAME ROLE AGE leader-locking-nfs-provisioner Role/leader-locking-nfs-provisioner 33d pod-rule-binding Role/pod-rule 8s role ClusterRole/admin 56m三、验证操作
切换到chenteng用户
[root@master rule]# kubectl config use-context chenteng@kubernetes Switched to context "chenteng@kubernetes". [root@master rule]# kubectl get pod NAME READY STATUS RESTARTS AGE nfs-provisioner-7d557769cd-dkb28 1/1 Running 4 33d nginx-v3-79dd7b64d8-l6kkc 1/1 Running 0 74m redis-6468bf6c84-qd66k 1/2 ImagePullBackOff 0 132m [root@master rule]# kubectl get pod -nkube-system Error from server (Forbidden): pods is forbidden: User "chenteng" cannot list resource "pods" in API group "" in the namespace "kube-system"
结论:可以看到当我们的用户绑定了再default命名空间下的rolebindings后,就有了前面role定义的一系列权限。
注意点- Role不受命名空间限制,RoleBinding是受命名空间限制的!
- 使用create创建RoleBinding时,-n指定命名空间来控制有哪个ns下的权限



