经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Kubernetes » 查看文章
Kubernetes(k8s)访问控制:权限管理之RBAC鉴权
来源:cnblogs  作者:人生的哲理  时间:2023/6/26 8:50:06  对本文有异议

一.系统环境

本文主要基于Kubernetes1.21.9和Linux操作系统CentOS7.4。

服务器版本 docker软件版本 Kubernetes(k8s)集群版本 CPU架构
CentOS Linux release 7.4.1708 (Core) Docker version 20.10.12 v1.21.9 x86_64

Kubernetes集群架构:k8scloude1作为master节点,k8scloude2,k8scloude3作为worker节点。

服务器 操作系统版本 CPU架构 进程 功能描述
k8scloude1/192.168.110.130 CentOS Linux release 7.4.1708 (Core) x86_64 docker,kube-apiserver,etcd,kube-scheduler,kube-controller-manager,kubelet,kube-proxy,coredns,calico k8s master节点
k8scloude2/192.168.110.129 CentOS Linux release 7.4.1708 (Core) x86_64 docker,kubelet,kube-proxy,calico k8s worker节点
k8scloude3/192.168.110.128 CentOS Linux release 7.4.1708 (Core) x86_64 docker,kubelet,kube-proxy,calico k8s worker节点

二.前言

Kubernetes作为目前最流行的容器编排平台之一,提供了强大的安全性能。在Kubernetes集群中,访问控制是保障集群安全的重要组成部分。其中,权限管理是访问控制的核心。本篇博客将介绍Kubernetes中的权限管理机制之RBAC鉴权。

使用RBAC鉴权的前提是已经有一套可以正常运行的Kubernetes集群,关于Kubernetes(k8s)集群的安装部署,可以查看博客《Centos7 安装部署Kubernetes(k8s)集群》https://www.cnblogs.com/renshengdezheli/p/16686769.html。

三.Kubernetes访问控制

用户使用 kubectl、客户端库或构造 REST 请求来访问 Kubernetes API。 用户账户和 Kubernetes 服务账号都可以被鉴权访问 API。 当请求到达 API 时,它会经历多个阶段,如下图所示:

image-20230620112925208

整体过程简述:请求发起方进行K8s API请求,建立 TLS 后,经过Authentication(认证)、Authorization(鉴权)、AdmissionControl(准入控制)三个阶段的校验,最后把请求转化为对K8s对象的变更操作持久化至etcd中。

关于Authentication(认证)详细内容请查看博客《Kubernetes(k8s)访问控制:身份认证》。

四.鉴权简介

在Kubernetes中,鉴权(Authorization)是指检查用户是否有权限执行请求所需的操作的过程。鉴权机制由Kubernetes API server实现,并可以支持RBAC(基于角色的访问控制)、ABAC(基于属性的访问控制)和Node鉴权等多种方式。

RBAC/ABAC/Node鉴权区别:

  • RBAC(Role-Based Access Control):基于角色的访问控制。RBAC允许管理员定义一系列角色,每个角色包含一组权限和资源。然后,将用户或者服务账户与相应的角色绑定起来。这样,用户或者服务账户就可以访问其相应的角色包含的资源和权限了。RBAC是Kubernetes推荐的鉴权方式。
  • ABAC(Attribute-Based Access Control):基于属性的访问控制。ABAC允许管理员定义一系列策略,每个策略包含多个属性,例如用户身份、资源类型、操作类型等。当一个请求被发送到API server时,API server会检查该请求是否满足所有匹配的策略。
  • Node鉴权:在Kubernetes中,每个节点都有主机名和IP地址。Node鉴权是指Kubernetes API server根据节点信息对请求进行授权的过程。可以使用Node鉴权来限制哪些节点可以访问某些资源。

在本篇博客中,我们将重点介绍RBAC鉴权。

五.配置客户端机器

如下是我们的kubernetes集群。

  1. [root@k8scloude1 ~]# kubectl get nodes -o wide
  2. NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
  3. k8scloude1 Ready control-plane,master 67d v1.21.0 192.168.110.130 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://20.10.12
  4. k8scloude2 Ready <none> 67d v1.21.0 192.168.110.129 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://20.10.12
  5. k8scloude3 Ready <none> 67d v1.21.0 192.168.110.128 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://20.10.12

先准备一台机器作为访问k8s集群的客户端,机器etcd1作为客户端,不是k8s集群的一部分。

访问k8s集群需要客户端工具kubectl,下面安装kubectl,--disableexcludes=kubernetes 表示禁掉除了这个之外的别的仓库。

  1. [root@etcd1 ~]# yum -y install kubectl-1.21.0-0 --disableexcludes=kubernetes

配置kubectl命令自动补全。

  1. [root@etcd1 ~]# vim /etc/profile
  2. [root@etcd1 ~]# grep source /etc/profile
  3. source <(kubectl completion bash)

使配置生效。

  1. [root@etcd1 ~]# source /etc/profile
  2. [root@etcd1 ~]# kubectl get node
  3. The connection to the server localhost:8080 was refused - did you specify the right host or port?

六.设置k8s集群允许所有请求访问

kubernetes默认的授权模式为:authorization-mode=Node,RBAC。

  1. [root@k8scloude1 ~]# ls /etc/kubernetes/manifests/kube-apiserver.yaml
  2. /etc/kubernetes/manifests/kube-apiserver.yaml
  3. [root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml
  4. - --authorization-mode=Node,RBAC

设置k8s允许所有请求访问。

  1. [root@k8scloude1 ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
  2. [root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml
  3. #- --authorization-mode=Node,RBAC
  4. - --authorization-mode=AlwaysAllow

重启kubelet使配置生效。

  1. [root@k8scloude1 ~]# systemctl restart kubelet
  2. [root@k8scloude1 ~]# systemctl status kubelet
  3. kubelet.service - kubelet: The Kubernetes Node Agent
  4. Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  5. Drop-In: /usr/lib/systemd/system/kubelet.service.d
  6. └─10-kubeadm.conf
  7. Active: active (running) since 2022-03-18 18:36:24 CST; 11s ago
  8. Docs: https://kubernetes.io/docs/
  9. Main PID: 28054 (kubelet)
  10. Memory: 42.4M
  11. CGroup: /system.slice/kubelet.service
  12. └─28054 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network-plugin=cni --pod-in...

当- --authorization-mode=AlwaysAllow 设置为允许所有请求之后,客户端机器可以随意访问所有资源。

kctest这个自定义的kubeconfig文件博客《Kubernetes(k8s)访问控制:身份认证》已经详细讲解过了,这里就不赘述了。

在etcd1机器上可以访问任何资源。

  1. [root@etcd1 ~]# kubectl get nodes --kubeconfig=kctest
  2. NAME STATUS ROLES AGE VERSION
  3. k8scloude1 Ready control-plane,master 68d v1.21.0
  4. k8scloude2 Ready <none> 68d v1.21.0
  5. k8scloude3 Ready <none> 68d v1.21.0
  6. [root@etcd1 ~]# kubectl get pod -A --kubeconfig=kctest
  7. NAMESPACE NAME READY STATUS RESTARTS AGE
  8. ingress-nginx ingress-nginx-admission-create-2lg57 0/1 Completed 0 31d
  9. ingress-nginx ingress-nginx-admission-patch-hd7p4 0/1 Completed 1 31d
  10. ingress-nginx ingress-nginx-controller-59b8bf5fdc-t2f7z 1/1 Running 14 31d
  11. kube-system calico-kube-controllers-6b9fbfff44-4jzkj 1/1 Running 78 68d
  12. kube-system calico-node-bdlgm 1/1 Running 38 68d
  13. kube-system calico-node-hx8bk 1/1 Running 38 68d
  14. kube-system calico-node-nsbfs 1/1 Running 38 68d
  15. kube-system coredns-545d6fc579-7wm95 1/1 Running 38 68d
  16. kube-system coredns-545d6fc579-87q8j 1/1 Running 38 68d
  17. kube-system etcd-k8scloude1 1/1 Running 38 68d
  18. kube-system kube-apiserver-k8scloude1 0/1 Running 1 8m36s
  19. kube-system kube-controller-manager-k8scloude1 1/1 Running 45 68d
  20. kube-system kube-proxy-599xh 1/1 Running 38 68d
  21. kube-system kube-proxy-lpj8z 1/1 Running 38 68d
  22. kube-system kube-proxy-zxlk9 1/1 Running 38 68d
  23. kube-system kube-scheduler-k8scloude1 1/1 Running 45 68d
  24. kube-system metrics-server-bcfb98c76-n4fnb 1/1 Running 42 60d
  25. metallb-system controller-7dcc8764f4-qdwl2 1/1 Running 24 34d
  26. metallb-system speaker-892pm 1/1 Running 16 34d
  27. metallb-system speaker-jfccb 1/1 Running 16 34d
  28. metallb-system speaker-nkrgk 1/1 Running 16 34d
  29. volume nfs-client-provisioner-76c576954d-5x7t2 1/1 Running 16 57d

七.设置k8s集群拒绝所有请求访问

设置k8s拒绝所有请求访问。

  1. [root@k8scloude1 ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
  2. #设置为拒绝所有请求
  3. [root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml
  4. #- --authorization-mode=Node,RBAC
  5. - --authorization-mode=AlwaysDeny

重启kubelet使配置生效。

  1. [root@k8scloude1 ~]# systemctl restart kubelet

设置为拒绝所有请求 - --authorization-mode=AlwaysDeny之后,客户端机器访问不了了。

  1. [root@etcd1 ~]# kubectl get pod -A --kubeconfig=kctest
  2. error: the server doesn't have a resource type "pod"
  3. [root@etcd1 ~]# kubectl get nodes --kubeconfig=kctest
  4. error: the server doesn't have a resource type "nodes"
  5. [root@etcd1 ~]# kubectl get node --kubeconfig=kctest
  6. error: the server doesn't have a resource type "node"

设置为拒绝所有请求 - --authorization-mode=AlwaysDeny之后,admin管理员用户无影响,其他用户访问不了。

  1. [root@k8scloude1 ~]# kubectl get node
  2. NAME STATUS ROLES AGE VERSION
  3. k8scloude1 Ready control-plane,master 68d v1.21.0
  4. k8scloude2 Ready <none> 68d v1.21.0
  5. k8scloude3 Ready <none> 68d v1.21.0

八.RBAC授权

RBAC支持基于角色的授权,即将一组权限分配给一个角色,再将该角色分配给一个或多个用户或服务账户。在Kubernetes中,RBAC鉴权由以下三个部分组成:

  1. Role:针对特定命名空间(Namespace)内的资源定义一组操作权限。
  2. RoleBinding:将Role和Subject(User或ServiceAccount)关联起来,以便Subject能够执行Role所定义的操作。
  3. ClusterRole和ClusterRoleBinding:类似于上述两个对象,但作用于整个集群。

8.1 role,rolebinding

想要使用RBAC授权,需要恢复- --authorization-mode=Node,RBAC,想要查看什么,都是我们敲命令获取,其实有很多我们看不到的操作(比如master和worker之间交互查询,审计等等),- --authorization-mode=Node 表示允许worker向master查询相应信息,想要--authorization-mode=Node生效,--enable-admission-plugins=NodeRestriction准入控制器要开启。

  1. [root@k8scloude1 ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
  2. [root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml
  3. - --authorization-mode=Node,RBAC
  4. #- --authorization-mode=AlwaysDeny

重启kubelet使配置生效。

  1. [root@k8scloude1 ~]# systemctl restart kubelet

管理员拥有所有权限,查看管理员的权限就可以知道k8s有哪些权限。

  1. [root@k8scloude1 ~]# kubectl describe clusterrole cluster-admin
  2. Name: cluster-admin
  3. Labels: kubernetes.io/bootstrapping=rbac-defaults
  4. Annotations: rbac.authorization.kubernetes.io/autoupdate: true
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. *.* [] [] [*]
  9. [*] [] [*]

可以看到admin角色对各种资源Resources的权限Verbs。

  1. [root@k8scloude1 ~]# kubectl describe clusterrole admin
  2. Name: admin
  3. Labels: kubernetes.io/bootstrapping=rbac-defaults
  4. Annotations: rbac.authorization.kubernetes.io/autoupdate: true
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. rolebindings.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch]
  9. roles.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch]
  10. ......
  11. services/proxy [] [] [get list watch create delete deletecollection patch update]
  12. bindings [] [] [get list watch]
  13. events [] [] [get list watch]
  14. limitranges [] [] [get list watch]
  15. namespaces/status [] [] [get list watch]
  16. namespaces [] [] [get list watch]
  17. persistentvolumeclaims/status [] [] [get list watch]
  18. pods/log [] [] [get list watch]
  19. pods/status [] [] [get list watch]
  20. replicationcontrollers/status [] [] [get list watch]
  21. ......
  22. pods.metrics.k8s.io [] [] [get list watch]
  23. ingresses.networking.k8s.io/status [] [] [get list watch]
  24. poddisruptionbudgets.policy/status [] [] [get list watch]
  25. serviceaccounts [] [] [impersonate create delete deletecollection patch update get list watch]

8.1.1 给test用户授予对pod的get和list权限

注意:RBAC不是直接把权限授予用户,而是把权限都放在角色role里,再把角色role绑定rolebinding到用户,这样用户就具有了相应的权限,注意对于命名空间ns1里的角色role1,命名空间ns2不能使用。

除了role,还有clusterrole,role是归属于某一个namespace,clusterrole是全局生效的,clusterrole除了可以使用rolebinding绑定之外,还可以使用clusterrolebingding绑定,rolebinding归属于某一个命名空间,clusterrolebingding全局生效。

查看角色role。

  1. [root@k8scloude1 ~]# kubectl get role
  2. No resources found in safe namespace.
  3. [root@k8scloude1 ~]# cd safe/

我们使用yaml文件的方式创建角色role :kubectl create role role1 --verb=get,list --resource=pods --dry-run=client -o yaml > role1.yaml。

--verb=get,list指定权限为get和list,--resource=pods表示权限作用在pod上。

  1. [root@k8scloude1 safe]# kubectl create role role1 --verb=get,list --resource=pods --dry-run=client -o yaml > role1.yaml

查看yaml文件,功能为:在 Kubernetes 集群中创建一个叫做 "role1" 的角色(Role),该角色具有操作(Kubernetes Pod)的权限。

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. #name: role1: 该角色的名称为 "role1"。
  8. name: role1
  9. #rules: 角色的规则部分定义了角色能够执行的操作列表。
  10. rules:
  11. #- apiGroups: [""]: apiGroups 字段指定资源所属的 API 组(或者不属于任何组)。在本例中,Pod 不属于任何 API 组,所以值为空字符串。
  12. - apiGroups:
  13. - ""
  14. #resources: ["pods"]: resources 字段指定角色能够访问的资源列表。在本例中,只有 Pod 是被授权的资源。
  15. resources:
  16. - pods
  17. #verbs: ["get", "list"]: verbs 字段列出了角色可用的动词列表。在本例中,角色可以执行 "get" 和 "list" 操作。这意味着此角色可以查看 Pod 的详细信息和列表信息。
  18. verbs:
  19. - get
  20. - list

生成role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 created

查看role。

  1. [root@k8scloude1 safe]# kubectl get role
  2. NAME CREATED AT
  3. role1 2022-03-19T09:52:13Z

查看role的权限:对pod具有get list权限。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. pods [] [] [get list]

把角色role1绑定到test用户上,test用户不属于任何命名空间。

  1. [root@k8scloude1 safe]# kubectl create rolebinding rolebind1 --role=role1 --user=test
  2. rolebinding.rbac.authorization.k8s.io/rolebind1 created

查看rolebinding。

  1. [root@k8scloude1 safe]# kubectl get rolebinding
  2. NAME ROLE AGE
  3. rolebind1 Role/role1 110s

查看rolebind1的描述信息。

  1. [root@k8scloude1 safe]# kubectl describe rolebinding rolebind1
  2. Name: rolebind1
  3. Labels: <none>
  4. Annotations: <none>
  5. Role:
  6. Kind: Role
  7. Name: role1
  8. Subjects:
  9. Kind Name Namespace
  10. ---- ---- ---------
  11. User test

在客户端进行权限测试,把角色role1绑定给test用户之后,客户端具有了safe命名空间里pod的查询权限。

  1. [root@etcd1 ~]# kubectl get pods --kubeconfig=kctest -n safe
  2. No resources found in safe namespace.

客户端不具有default命名空间里pod的查询权限。

  1. [root@etcd1 ~]# kubectl get pods --kubeconfig=kctest
  2. Error from server (Forbidden): pods is forbidden: User "test" cannot list resource "pods" in API group "" in the namespace "default"

8.1.2 增加对pod的创建权限

如下是使用nginx镜像创建pod的配置文件。

  1. [root@etcd1 ~]# cat pod.yaml
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5. labels:
  6. test: podtest
  7. name: podtest
  8. spec:
  9. #当需要关闭容器时,立即杀死容器而不等待默认的30秒优雅停机时长。
  10. terminationGracePeriodSeconds: 0
  11. containers:
  12. - name: nginx
  13. image: nginx
  14. #imagePullPolicy: IfNotPresent:表示如果本地已经存在该镜像,则不重新下载;否则从远程 Docker Hub 下载该镜像
  15. imagePullPolicy: IfNotPresent

现在想在客户端创建一个pod,用户test只对pod有get ,list权限,没有创建pod权限,创建失败。

  1. [root@etcd1 ~]# kubectl apply -f pod.yaml -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): error when creating "pod.yaml": pods is forbidden: User "test" cannot create resource "pods" in API group "" in the namespace "safe"

修改yaml文件,添加pod的create权限。

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. name: role1
  8. rules:
  9. - apiGroups:
  10. - ""
  11. resources:
  12. - pods
  13. #添加了创建权限create
  14. verbs:
  15. - get
  16. - list
  17. - create

应用role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 configured

现在role1具有了对pod的get list create权限。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. pods [] [] [get list create]

role1添加pod的create权限之后,成功在客户端创建pod。

  1. [root@etcd1 ~]# kubectl apply -f pod.yaml -n safe --kubeconfig=kctest
  2. pod/podtest created
  3. [root@etcd1 ~]# kubectl get pod -n safe --kubeconfig=kctest
  4. NAME READY STATUS RESTARTS AGE
  5. podtest 1/1 Running 0 22s

8.1.3 增加对pod的删除权限

用户test没有pod删除权限。

  1. [root@etcd1 ~]# kubectl delete pod podtest -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): pods "podtest" is forbidden: User "test" cannot delete resource "pods" in API group "" in the namespace "safe"

给角色role1增加删除pod的权限。

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. name: role1
  8. rules:
  9. - apiGroups:
  10. - ""
  11. resources:
  12. - pods
  13. #增加删除权限delete
  14. verbs:
  15. - get
  16. - list
  17. - create
  18. - delete

应用role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 configured

现在role1具有了对pod的get list create delete权限。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. pods [] [] [get list create delete]

给角色role1增加删除pod的权限之后,客户端成功删除了pod。

  1. [root@etcd1 ~]# kubectl delete pod podtest -n safe --kubeconfig=kctest
  2. pod "podtest" deleted
  3. [root@etcd1 ~]# kubectl get pod -n safe --kubeconfig=kctest
  4. No resources found in safe namespace.

8.1.4 增加对svc的get list create delete权限

test用户没有对services的list权限。

  1. [root@etcd1 ~]# kubectl get svc -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): services is forbidden: User "test" cannot list resource "services" in API group "" in the namespace "safe"

修改yaml文件,对role1添加service的get list create delete权限,注意:services不能简写。

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. name: role1
  8. rules:
  9. - apiGroups:
  10. - ""
  11. #资源里增加services
  12. resources:
  13. - pods
  14. - services
  15. verbs:
  16. - get
  17. - list
  18. - create
  19. - delete

应用role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 configured

查看角色的描述信息,角色role1增加了services的get list create delete权限。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. pods [] [] [get list create delete]
  9. services [] [] [get list create delete]

给角色role1增加了services的get list create delete权限之后,客户端可以查询svc了。

  1. [root@etcd1 ~]# kubectl get svc -n safe --kubeconfig=kctest
  2. No resources found in safe namespace.

8.1.5 增加对deployments的get list create delete权限

客户端没有对deployments的list权限。

  1. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "safe"

修改yaml文件,给role1添加deployments的get list create delete权限。

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. name: role1
  8. rules:
  9. - apiGroups:
  10. - ""
  11. resources:
  12. - pods
  13. - services
  14. - deployments
  15. verbs:
  16. - get
  17. - list
  18. - create
  19. - delete

应用role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 configured

查看角色的描述信息,角色role1增加了deployments的get list create delete权限。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. deployments [] [] [get list create delete]
  9. pods [] [] [get list create delete]
  10. services [] [] [get list create delete]

给角色role1增加了deployments的get list create delete权限之后,客户端还是没有对deployments的list权限。

  1. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "safe"

给角色role1增加了deployments的get list create delete权限之后,客户端还是没有对deployments的list权限,原因为:pod,service对应的apiVersion为v1,deploy对应的apiVersion为apps/v1

apiVersion的结构有 xx ,yy/zz ,对于xx结构,apiGroups写为:apiGroups:"",对于yy/zz结构,apiGroups写为:apiGroups:"yy"。

如果apiGroups只写为“”,不写"apps"则pods,services生效,deployments不生效,因为没有父级,如果apiGroups只写为"apps",不写""则pods,services不生效,deployments生效,因为pods,services没有父级。

下面才是正确的写法,修改yaml文件。

  1. [root@k8scloude1 safe]# vi role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. name: role1
  8. rules:
  9. #- apiGroups: ["apps"]: apiGroups 字段指定资源所属的 API 组(或者不属于任何组)。在本例中,deployments 属于 apps/v1 组,所以值为apps。
  10. - apiGroups:
  11. - ""
  12. - "apps"
  13. resources:
  14. - pods
  15. - services
  16. - deployments
  17. verbs:
  18. - get
  19. - list
  20. - create
  21. - delete

应用role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 configured

查看role1的描述信息。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. deployments [] [] [get list create delete]
  9. pods [] [] [get list create delete]
  10. services [] [] [get list create delete]
  11. deployments.apps [] [] [get list create delete]
  12. pods.apps [] [] [get list create delete]
  13. services.apps [] [] [get list create delete]

给role1添加deployment的get list create delete权限之后,客户端可以查询deploy了。

  1. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  2. No resources found in safe namespace.

如下是使用Nginx镜像创建deploy的yaml文件。

  1. [root@etcd1 ~]# cat nginx.yaml
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5. creationTimestamp: null
  6. labels:
  7. app: nginx
  8. name: nginx
  9. spec:
  10. #5个副本
  11. replicas: 5
  12. selector:
  13. matchLabels:
  14. app: nginx
  15. strategy: {}
  16. template:
  17. metadata:
  18. creationTimestamp: null
  19. labels:
  20. app: nginx
  21. spec:
  22. #当需要关闭容器时,立即杀死容器而不等待默认的30秒优雅停机时长。
  23. terminationGracePeriodSeconds: 0
  24. containers:
  25. - image: nginx
  26. name: nginx
  27. #imagePullPolicy: IfNotPresent:表示如果本地已经存在该镜像,则不重新下载;否则从远程 Docker Hub 下载该镜像
  28. imagePullPolicy: IfNotPresent
  29. resources: {}
  30. status: {}

在客户端创建deploy,由于被授权了,deploy创建成功。

  1. [root@etcd1 ~]# kubectl apply -f nginx.yaml -n safe --kubeconfig=kctest
  2. deployment.apps/nginx created
  3. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  4. NAME READY UP-TO-DATE AVAILABLE AGE
  5. nginx 5/5 5 5 23s
  6. [root@etcd1 ~]# kubectl get pod -n safe --kubeconfig=kctest
  7. NAME READY STATUS RESTARTS AGE
  8. nginx-6cf858f6cf-62m8t 1/1 Running 0 72s
  9. nginx-6cf858f6cf-74nzb 1/1 Running 0 72s
  10. nginx-6cf858f6cf-bw84g 1/1 Running 0 72s
  11. nginx-6cf858f6cf-cmj95 1/1 Running 0 72s
  12. nginx-6cf858f6cf-fzs4l 1/1 Running 0 72s

刚才给role1添加deployments权限写的不好,如下为优化后的写法:

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. #对于给role1添加权限还可以有另一种写法(这种方法更好),如下
  3. [root@k8scloude1 safe]# cat role1.yaml
  4. apiVersion: rbac.authorization.k8s.io/v1
  5. kind: Role
  6. metadata:
  7. creationTimestamp: null
  8. name: role1
  9. rules:
  10. - apiGroups:
  11. - ""
  12. resources:
  13. - pods
  14. - services
  15. verbs:
  16. - get
  17. - list
  18. - create
  19. - delete
  20. - apiGroups:
  21. - "apps"
  22. resources:
  23. - deployments
  24. verbs:
  25. - get
  26. - list
  27. - create
  28. - delete

8.1.6 增加对deployments的patch权限

把nginx的deploy的副本数变为2,发现用户test没有deployments/scale的patch权限。

  1. [root@etcd1 ~]# kubectl scale deploy nginx --replicas=2 -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): deployments.apps "nginx" is forbidden: User "test" cannot patch resource "deployments/scale" in API group "apps" in the namespace "safe"

修改yaml文件,添加deployments/scale的patch权限。

  1. [root@k8scloude1 safe]# vim role1.yaml
  2. [root@k8scloude1 safe]# cat role1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6. creationTimestamp: null
  7. name: role1
  8. rules:
  9. - apiGroups:
  10. - ""
  11. resources:
  12. - pods
  13. - services
  14. - deployments
  15. verbs:
  16. - get
  17. - list
  18. - create
  19. - delete
  20. - apiGroups:
  21. - "apps"
  22. resources:
  23. - deployments
  24. - deployments/scale
  25. verbs:
  26. - get
  27. - list
  28. - create
  29. - delete
  30. - patch

应用role。

  1. [root@k8scloude1 safe]# kubectl apply -f role1.yaml
  2. role.rbac.authorization.k8s.io/role1 configured

查看role1的描述信息。

  1. [root@k8scloude1 safe]# kubectl describe role role1
  2. Name: role1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. deployments.apps/scale [] [] [get list create delete patch]
  9. deployments.apps [] [] [get list create delete patch]
  10. deployments [] [] [get list create delete]
  11. pods [] [] [get list create delete]
  12. services [] [] [get list create delete]

添加deployments/scale的patch权限之后,客户端可以修改副本数了。

  1. [root@etcd1 ~]# kubectl scale deploy nginx --replicas=2 -n safe --kubeconfig=kctest
  2. deployment.apps/nginx scaled
  3. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  4. NAME READY UP-TO-DATE AVAILABLE AGE
  5. nginx 2/2 2 2 7m19s

删除deploy。

  1. [root@etcd1 ~]# kubectl delete -f nginx.yaml -n safe --kubeconfig=kctest
  2. deployment.apps "nginx" deleted
  3. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  4. No resources found in safe namespace.

8.2 clusterrole,clusterrolebinding

上面做的权限都是role,rolebinding,下面开始clusterrole,clusterrolebinding。

删除role。

  1. [root@k8scloude1 safe]# kubectl get role
  2. NAME CREATED AT
  3. role1 2022-03-19T09:52:13Z
  4. [root@k8scloude1 safe]# kubectl delete -f role1.yaml
  5. role.rbac.authorization.k8s.io "role1" deleted
  6. [root@k8scloude1 safe]# kubectl get role
  7. No resources found in safe namespace.

删除rolebinding。

  1. [root@k8scloude1 safe]# kubectl get rolebinding
  2. NAME ROLE AGE
  3. rolebind1 Role/role1 25h
  4. [root@k8scloude1 safe]# kubectl delete rolebinding rolebind1
  5. rolebinding.rbac.authorization.k8s.io "rolebind1" deleted
  6. [root@k8scloude1 safe]# kubectl get rolebinding
  7. No resources found in safe namespace.

8.2.1 test用户授予对Pod、Service 、Deployment 的get 和 create 权限

生成创建clusterrole的yaml文件,--verb指定权限,--resource指定作用的资源。

  1. [root@k8scloude1 safe]# kubectl create clusterrole clusterrole1 --verb=get,create --resource=pod,svc,deploy --dry-run=client -o yaml >clusterrole1.yaml

查看ClusterRole的yaml文件,功能为:在 Kubernetes 集群中创建一个叫做 "clusterrole1" 的集群角色(ClusterRole),该角色具有对 Pod、Service 和 Deployment 资源的操作权限。

使用这个 YAML 文件在 Kubernetes 中创建 "clusterrole1" 集群角色后,该角色将能够访问 Pod、Service 和 Deployment 资源,并且具有 get 和 create 操作权限。

  1. [root@k8scloude1 safe]# vim clusterrole1.yaml
  2. [root@k8scloude1 safe]# cat clusterrole1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. #kind: ClusterRole: ClusterRole 是 Kubernetes 集群级别的角色授权机制,与 Role 类似,但是它可以跨命名空间使用。
  5. kind: ClusterRole
  6. metadata:
  7. creationTimestamp: null
  8. name: clusterrole1
  9. rules:
  10. - apiGroups:
  11. - ""
  12. resources:
  13. - pods
  14. - services
  15. verbs:
  16. - get
  17. - create
  18. - apiGroups:
  19. - apps
  20. resources:
  21. - deployments
  22. verbs:
  23. - get
  24. - create

应用clusterrole。

  1. [root@k8scloude1 safe]# kubectl apply -f clusterrole1.yaml
  2. clusterrole.rbac.authorization.k8s.io/clusterrole1 created

查看clusterrole。

  1. [root@k8scloude1 safe]# kubectl get clusterrole | grep clusterrole1
  2. clusterrole1 2022-03-20T11:24:36Z

kubernetes集群自带的clusterrole有很多。

  1. [root@k8scloude1 safe]# kubectl get clusterrole | wc -l
  2. 75

把集群角色clusterrole1使用clusterrolebinding绑定给用户test。

  1. [root@k8scloude1 safe]# kubectl create clusterrolebinding clusterrolebinding1 --clusterrole=clusterrole1 --user=test
  2. clusterrolebinding.rbac.authorization.k8s.io/clusterrolebinding1 created

查看clusterrolebinding。

  1. [root@k8scloude1 safe]# kubectl get clusterrolebinding | grep clusterrolebinding1
  2. clusterrolebinding1 ClusterRole/clusterrole1 25s
  3. [root@k8scloude1 safe]# kubectl get clusterrolebinding | wc -l
  4. 60

查看集群绑定的描述信息。

  1. [root@k8scloude1 safe]# kubectl describe clusterrolebinding clusterrolebinding1
  2. Name: clusterrolebinding1
  3. Labels: <none>
  4. Annotations: <none>
  5. Role:
  6. Kind: ClusterRole
  7. Name: clusterrole1
  8. Subjects:
  9. Kind Name Namespace
  10. ---- ---- ---------
  11. User test

查看集群角色的描述信息。

  1. [root@k8scloude1 safe]# kubectl describe clusterrole clusterrole1
  2. Name: clusterrole1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. pods [] [] [get create]
  9. services [] [] [get create]
  10. deployments.apps [] [] [get create]

8.2.2 增加list权限

在客户端进行测试,设置了clusterrole,clusterrolebinding之后,发现用户test没有对deploy的list权限。

  1. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  2. Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "safe"

修改yaml文件,增加list权限。

  1. [root@k8scloude1 safe]# vim clusterrole1.yaml
  2. #添加list权限
  3. [root@k8scloude1 safe]# cat clusterrole1.yaml
  4. apiVersion: rbac.authorization.k8s.io/v1
  5. kind: ClusterRole
  6. metadata:
  7. creationTimestamp: null
  8. name: clusterrole1
  9. rules:
  10. - apiGroups:
  11. - ""
  12. resources:
  13. - pods
  14. - services
  15. verbs:
  16. - get
  17. - create
  18. - list
  19. - apiGroups:
  20. - apps
  21. resources:
  22. - deployments
  23. verbs:
  24. - get
  25. - create
  26. - list

应用clusterrole。

  1. [root@k8scloude1 safe]# kubectl apply -f clusterrole1.yaml
  2. clusterrole.rbac.authorization.k8s.io/clusterrole1 configured

查看clusterrole1的描述信息。

  1. [root@k8scloude1 safe]# kubectl describe clusterrole clusterrole1
  2. Name: clusterrole1
  3. Labels: <none>
  4. Annotations: <none>
  5. PolicyRule:
  6. Resources Non-Resource URLs Resource Names Verbs
  7. --------- ----------------- -------------- -----
  8. pods [] [] [get create list]
  9. services [] [] [get create list]
  10. deployments.apps [] [] [get create list]

clusterrole1添加了list权限之后,客户端可以get信息了。

  1. [root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest
  2. No resources found in safe namespace.
  3. [root@etcd1 ~]# kubectl get deploy -n default --kubeconfig=kctest
  4. No resources found in default namespace.

可以发现,clusterrolebinding全局生效,在所有namespace里都生效。

  1. [root@etcd1 ~]# kubectl get deploy -n kube-system --kubeconfig=kctest
  2. NAME READY UP-TO-DATE AVAILABLE AGE
  3. calico-kube-controllers 1/1 1 1 70d
  4. coredns 2/2 2 2 70d
  5. metrics-server 1/1 1 1 69d

九.总结

在本篇博客中,我们介绍了Kubernetes中的权限管理机制之RBAC鉴权。通过创建Role、RoleBinding、ClusterRole和ClusterRoleBinding等对象,管理员可以有效地控制用户和服务账户的访问权限,保障集群的安全性。

除了RBAC、ABAC和Node鉴权外,Kubernetes还支持Webhook鉴权、Service Account Token Volume Projection等多种鉴权方式。同时,在进行权限管理时,管理员还需注意以下事项:

  1. 避免为用户授予过多的权限。
  2. 确保所有操作都可以被审计和跟踪。
  3. 定期审核访问权限,确保其符合组织政策和最佳实践。

原文链接:https://www.cnblogs.com/renshengdezheli/p/17504354.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号