关于 Kubernetes中API Server授权(RBAC)管理的一些笔记
写在前面
- 学习
K8s涉及，整理笔记记忆 - 博文偏实战，内容涉及：
我也突然懂得，原来痛苦、失望和悲愁不是为了惹恼我们，使我们气馁或者无地自容；它们的存在，是为了使我们心智成熟，臻于完善。 ——赫尔曼·黑塞《彼得·卡门青》
API Server授权管理
环境版本
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl get nodesNAME STATUS ROLES AGE VERSIONvms81.liruilongs.github.io Ready control-plane,master 41d v1.22.2vms82.liruilongs.github.io Ready <none> 41d v1.22.2vms83.liruilongs.github.io Ready <none> 41d v1.22.2除了k8s集群，我们还用到了集群外的机器liruilongs.github.io,这个机器作为客户器，安装了kubectl客户端，以上传了liruilong用户的kubeconfig证书文件,但是没有绑定角色
命名空间环境准备
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl create ns liruilong-rbac-createnamespace/liruilong-rbac-create created┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$mkdir k8s-rbac-create;cd k8s-rbac-create┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl config set-context $(kubectl config current-context) --namespace=liruilong-rbac-createContext "kubernetes-admin@kubernetes" modified.┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$授权策略简述
当客户端发起API Server调用时, API Server内部要先进行用户认证,然后执行用户鉴权流程,即通过鉴权策略来决定一个API调用是否合法。想来对于开发的小伙伴并不陌生，常用的Spring Security等安全框架，都会涉及认证和鉴权的过程。
既然鉴权，那必有授权的过程，简单地说,授权就是授予不同的用户不同的访问权限。
API Server目前支持以下几种授权策略
| 策略 | 描述 |
|---|---|
| AlwaysDeny | 表示拒绝所有请求,一般用于测试。 |
| AlwaysAllow | 允许接收所有请求,如果集群不需要授权流程,则可以采用该策略,这也是Kubernetes的默认配置。 |
| ABAC | (Attribute-Based Access Control)基于属性的访问控制,表示使用用户配置的授权规则对用户请求进行匹配和控制。 |
| Webhook | 通过调用外部REST服务对用户进行授权。 |
| RBAC | (Role-Based Access Control)基于角色的访问控制。 |
| Node | 是一种专用模式,用于对kubelet发出的请求进行访问控制。 |
策略的设置通过通过API Server的启动参数"--authorization-mode"设置。
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep authorization-mode - --authorization-mode=Node,RBAC┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$关于授权策略，AlwaysAllow和AlwaysDeny不多讲，ABAC不够灵活，Node授权器主要用于各个node上的kubelet访问apiserver时使用的，其他一般均由RBAC授权器来授权,下面我们看看RBAC的权限策略
RBAC授权模式
这一块，官方文档写的很详细，详细学习，小伙伴还是去官网看看，这里讲一些常用的完整Demo，官网地址：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
RBAC（Role-Based Access Control，基于角色的访问控制）即权限是和角色相关的,而用户则被分配相应的角色作为其成员。
在
Kubernetes的1.5版本中引入，在1.6版本时升级为Beta版本，在1.8版本时升级为GA。作为kubeadm安装方式的默认选项，相对于其他访问控制方式，新的RBAC具有如下优势。
- 对集群中的资源和非资源权限均有完整的覆盖。
- 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用
kubectl或API进行操作。 - 可以在运行时进行调整，无须重新启动
API Server。
要使用RBAC授权模式，需要在API Server的启动参数中加上–authorization-mode=RBAC,如果小伙伴默认使用kubeadm安装，那么默认使用Node,RBAC两种策略
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep authorization-mode - --authorization-mode=Node,RBACRBAC的API资源对象引入了4个新的顶级资源对象:
RoleClusterRoleRoleBindingClusterRoleBinding
同其他API资源对象一样,用户可以使用kubectl或者API调用等方式操作这些资源对象。
角色
角色(Role)一个角色就是一组权限的集合。在同一个命名空间中,可以用Role来定义一个角色,如果是集群级别的,就需要使用ClusterRole了。角色只能对命名空间内的资源进行授权
集群角色(ClusterRole)集群角色除了具有和角色一致的, 命名空间内资源的管理能力,因其集群级别的范围,还可以用于以下特殊元素的授权。
- 集群范围的资源,例如Node.
- 非资源型的路径,例如“/api"
- 包含全部命名空间的资源,例如pods (用于
kubectl get pods -all-namespaces这样的操作授权)。
下面我们找一个集群中内置的集群角色管理员看看详细信息
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl describe clusterrole adminName: adminLabels:kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate: truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- rolebindings.rbac.authorization.k8s.io [] [][create delete deletecollection get list patch update watch] roles.rbac.authorization.k8s.io [] [][create delete deletecollection get list patch update watch] configmaps [] [][create delete deletecollection patch update get list watch] events[] [][create delete deletecollection patch update get list watch] persistentvolumeclaims [] [][create delete deletecollection patch update get list watch] pods [] [][create delete deletecollection patch update get list watch] replicationcontrollers/scale [] [][create delete deletecollection patch update get list watch].........┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$在上面的管理员集群角色中，
Resources列为允许访问的资源，Verbs列为允许操作的行为或者动作
角色绑定
有个角色，那么角色和用户或者用户组是如何绑定的，这里就需要角色绑定这个资源对象了，不知道小伙记不记得，我们在做认证的时候，有一个授权的动作
给用户授权，这里给 liruilong 一个集群角色 cluster-role(cluster-admin类似于root一样的角色)，这样 liruilong 具有管理员权限
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl create clusterrolebinding test --clusterrole=cluster-admin --user=liruilongclusterrolebinding.rbac.authorization.k8s.io/test created┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$在这里，我们把cluster-admin这个集群角色绑定到了用户liruilong，cluster-admin这个角色相当于是一个root用户的角色
角色绑定(RoleBinding)和集群角色绑定(ClusterRoleBinding) :用来把一个角色绑定到一个目标上,绑定目标可以是User (用户) 、Group (组)或者Service Account。
在一般情况下，使用RoleBinding为某个命名空间授权,使用ClusterRoleBinding为集群范围内授权。
角色绑定的区别：
RoleBinding(角色绑定)可以引用Role进行授权。也可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权
ClusterRoleBinding(集群角色绑定)中的角色只能是集群角色(ClusterRole)，用于进行集群级别或者对所有命名空间都生效的授权
实战
角色创建
查看系统中角色
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl get roleNo resources found in liruilong-rbac-create namespace.创建一个role角色资源对象
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl create role role-liruilong --verb=get,list,watch --resource=pod --dry-run=client -o yaml这里我们创建一个角色，名字叫role-liruilong,定义这个角色拥有pod资源的查看详细信息，列表查看，监听，创建的权限
查看资源文件
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role-liruilongrules:- apiGroups: - "" resources: - pods verbs: - get - list - watch - create资源文件属性
- apiGroups：支持的
API组列表，例如“apiVersion:batch/v1”,“apiVersion: extensions:v1beta1”,“apiVersion: apps/v1beta1”等 - resources：支持的
资源对象列表，例如pods、deployments、jobs等。 - verbs：对
资源对象的操作方法列表，例如get、watch、list、delete、replace、patch等
通过yaml文件创建一个role资源对象
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl create role role-liruilong --verb=get,list,watch,create --resource=pod --dry-run=client -o yaml >role-liruilong.yaml┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl apply -f role-liruilong.yamlrole.rbac.authorization.k8s.io/role-liruilong created查看角色信息
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl get roleNAME CREATED ATrole-liruilong 2022-01-23T13:17:15Z查看角色详细信息
┌──[root@vms81.liruilongs.github.io]-[~/ansible]└─$kubectl describe role role-liruilongName: role-liruilongLabels:<none>Annotations: <none>PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods[] [][get list watch create]创建角色绑定
绑定角色到liruilong用户
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl create rolebinding rbind-liruilong --role=role-liruilong --user=liruilongrolebinding.rbac.authorization.k8s.io/rbind-liruilong created查看角色绑定
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl get rolebindingsNAMEROLE AGErbind-liruilong Role/role-liruilong 23s查看绑定角色的详细信息
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl describe rolebindings rbind-liruilongName: rbind-liruilongLabels:<none>Annotations: <none>Role: Kind: Role Name: role-liruilongSubjects: Kind NameNamespace ---- ------------- User liruilong┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$然后我们在客户机访问测试
这里使用我们之前创建的kubeonfig证书，我们之前创建证书也是基于用户liruilong的
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl config view | grep namesp namespace: liruilong-rbac-create 修改一下kubeonfig证书的命名空间
┌──[root@liruilongs.github.io]-[~]└─$ cat kc1 | grep namesp namespace: default┌──[root@liruilongs.github.io]-[~]└─$ sed 's#namespace: default#namespace: liruilong-rbac-create#g' kc1 | grep namesp namespace: liruilong-rbac-create┌──[root@liruilongs.github.io]-[~]└─$ sed -i 's#namespace: default#namespace: liruilong-rbac-create#g' kc1 | grep namesp在客户机指定kubeconfig文件测试，认证和鉴权没有问题，当前命名空间没有资源对象
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get podsNo resources found in liruilong-rbac-create namespace. 然后我们在客户机创建一个pod
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 run pod-demo --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml >pod-demo.yaml查看pod资源，创建成功
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get podsNAMEREADY STATUS RESTARTS AGEpod-demo 1/1 Running 0 28m删除一个pod，因为没有授权删除的权限，所以无法删除
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 delete pod pod-demoError from server (Forbidden): pods "pod-demo" is forbidden: User "liruilong" cannot delete resource "pods" in API group "" in the namespace "liruilong-rbac-create"┌──[root@liruilongs.github.io]-[~]└─$回到集群，添加删除的角色
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$vim role-liruilong.yaml┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl apply -f role-liruilong.yamlrole.rbac.authorization.k8s.io/role-liruilong configuredapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role-liruilongrules:- apiGroups: - "" resources: - pods verbs: - get - list - watch - create - delete重新删除，pod删除成功
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 delete pod pod-demoError from server (Forbidden): pods "pod-demo" is forbidden: User "liruilong" cannot delete resource "pods" in API group "" in the namespace "liruilong-rbac-create"┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 delete pod pod-demopod "pod-demo" deleted┌──[root@liruilongs.github.io]-[~]└─$这里我们查看SVC信息，发现没有权限
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get svcError from server (Forbidden): services is forbidden: User "liruilong" cannot list resource "services" in API group "" in the namespace "liruilong-rbac-create"提示我们用户liruilong需要添加services资源权限
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$vim role-liruilong.yaml┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl apply -f role-liruilong.yamlrole.rbac.authorization.k8s.io/role-liruilong configuredapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role-liruilongrules:- apiGroups: - "" resources: - pods - services - deployments verbs: - get - list - watch - create - delete这里我们在集群中添加svc和deploy。然后在客户机访问测试，之前访问没有权限，现在提示命名空间中没有资源，说明鉴权成功
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get svcNo resources found in liruilong-rbac-create namespace.┌──[root@liruilongs.github.io]-[~]└─$但是我们访问deploy的时候，提示报错，没有权限，什么原因呢，这就涉及到一个- apiGroups:的原因
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get deploymentsError from server (Forbidden): deployments.apps is forbidden: User "liruilong" cannot list resource "deployments" in API group "apps" in the namespace "liruilong-rbac-create"┌──[root@liruilongs.github.io]-[~]└─$我们查看api资源对象，发现deployments和service的版本定义不同，一个是apps/v1，一个是v1,资源对象定义的yaml文件中apiGroups字段用于定义版本组别。
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl api-resources | grep podspods po v1 true Podpods metrics.k8s.io/v1beta1 true PodMetricspodsecuritypolicies psp policy/v1beta1 false PodSecurityPolicy┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl api-resources | grep deploydeployments deployapps/v1 true Deployment┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl api-resources | grep serviceserviceaccounts sa v1 true ServiceAccountservices svc v1 true Serviceapiservices apiregistration.k8s.io/v1false APIServiceservicemonitors monitoring.coreos.com/v1 true ServiceMonitor┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$修改资源配置文件，添加v1的的上一级apps
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$vim role-liruilong.yaml┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl apply -f role-liruilong.yamlrole.rbac.authorization.k8s.io/role-liruilong configuredapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role-liruilongrules:- apiGroups: - "" - "apps" resources: - pods - services - deployments verbs: - get - list - watch - create - delete客户机访问测试，鉴权成功，但是没有相关的deploy资源
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get deploymentsError from server (Forbidden): deployments.apps is forbidden: User "liruilong" cannot list resource "deployments" in API group "apps" in the namespace "liruilong-rbac-create"┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get deploymentsNo resources found in liruilong-rbac-create namespace.┌──[root@liruilongs.github.io]-[~]└─$这里我们在客户机创建一个deploy
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 create deployment web-liruilong --image=nginx --replicas=2 --dry-run=client -o yamlapiVersion: apps/v1kind: Deploymentmetadata: creationTimestamp: null labels: app: web-liruilong name: web-liruilongspec: replicas: 2 selector: matchLabels: app: web-liruilong strategy: {} template: metadata: creationTimestamp: null labels: app: web-liruilong spec: containers: - image: nginx name: nginx resources: {}status: {}┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 create deployment web-liruilong --image=nginx --replicas=2 --dry-run=client -o yaml >web-liruilong.yaml创建成功，查看deploy的资源，可以正常查看
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 apply -f web-liruilong.yamldeployment.apps/web-liruilong created┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEweb-liruilong 0/2 2 0 31s┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get podsNAMEREADY STATUSRESTARTS AGEweb-liruilong-c546cb69b-g2pvm 0/1 ContainerCreating 0 59sweb-liruilong-c546cb69b-w6xfh 0/1 ContainerCreating 0 59s┌──[root@liruilongs.github.io]-[~]└─$但是我们修改deplo的副本数量时，会报错，这是什么原因呢，提示我们少了patch权限，没办法修改deploy的副本数量
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 scale deployment web-liruilong --replicas=3Error from server (Forbidden): deployments.apps "web-liruilong" is forbidden: User "liruilong" cannot patch resource "deployments/scale" in API group "apps" in the namespace "liruilong-rbac-create"┌──[root@liruilongs.github.io]-[~]└─$同样，添加patch权限
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$vim role-liruilong.yaml┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl apply -f role-liruilong.yamlrole.rbac.authorization.k8s.io/role-liruilong configuredapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role-liruilongrules:- apiGroups: - "" - "apps" resources: - pods - services - deployments - deployments/scale verbs: - get - list - watch - create - delete - patch在次执行命令，可以正常修改deploy的副本
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 scale deployment web-liruilong --replicas=3deployment.apps/web-liruilong scaled┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEweb-liruilong 2/3 3 2 7m43s┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get podsNAMEREADY STATUSRESTARTS AGEweb-liruilong-c546cb69b-52nqm 0/1 ContainerCreating 0 16sweb-liruilong-c546cb69b-g2pvm 1/1 Running 0 7m50sweb-liruilong-c546cb69b-w6xfh 1/1 Running 0 7m50s┌──[root@liruilongs.github.io]-[~]└─$当然，资源文件也可以分开写
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role-liruilongrules:- apiGroups: - "" resources: - pods - services verbs: - get - list - watch - create - delete- apiGroups: - "apps" resources: - deployments - deployments/scale verbs: - get - list - watch - create - delete - patch创建集群角色
角色是基于命名空间的，即不同的命名空间基于角色的权限不会受影响，这里我们需要把角色定义为全局生效，就需要集群角色
我们用之前的角色修改一下资源文件，将资源类型修改为集群角色ClusterRole
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$sed 's#kind: Role#kind: ClusterRole#g' role-liruilong.yaml | grep kindkind: ClusterRole┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$sed -i 's#kind: Role#kind: ClusterRole#g' role-liruilong.yaml | grep kind┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl apply -f role-liruilong.yamlclusterrole.rbac.authorization.k8s.io/role-liruilong created┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$同时需要把集群角色和用户liruilong绑定
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl get clusterrolebindings | grep liruilongcbind-liruilong ClusterRole/role-liruilong 2m29s┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$查看pod资源list，不但可以查看当前命名空间，也可以查看default、kube-system命名空间的
┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get podsNo resources found in liruilong-rbac-create namespace.┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get pods -n defaultNo resources found in default namespace.┌──[root@liruilongs.github.io]-[~]└─$kubectl --kubeconfig=kc1 get pods -n kube-systemNAMEREADY STATUS RESTARTS AGEcalico-kube-controllers-78d6f96c7b-85rv9 1/1 Running 272 (5m49s ago) 39dcalico-node-6nfqv 1/1 Running 290 (41m ago) 41dcalico-node-fv458 0/1 Running 50 41dcalico-node-h5lsq 1/1 Running 98 (17m ago) 41dcoredns-7f6cbbb7b8-ncd2s 1/1 Running 21 (6d14h ago) 39dcoredns-7f6cbbb7b8-pjnct 1/1 Running 20 (6d14h ago) 39detcd-vms81.liruilongs.github.io 1/1 Running 126 (8h ago) 41dkube-apiserver-vms81.liruilongs.github.io 1/1 Running 12 (8h ago)7d10hkube-controller-manager-vms81.liruilongs.github.io 1/1 Running 88 (8h ago)40dkube-proxy-scs6x 1/1 Running 10 (7d22h ago) 41dkube-proxy-tbwz5 1/1 Running 22 (6d14h ago) 41dkube-proxy-xccmp 1/1 Running 6 (8d ago) 41dkube-scheduler-vms81.liruilongs.github.io 1/1 Running 242 (8h ago) 41dmetrics-server-bcfb98c76-ktgnj 1/1 Running 0 6d┌──[root@liruilongs.github.io]-[~]└─$删除角色、角色绑定
删除角色、角色绑定
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl delete role role-liruilongrole.rbac.authorization.k8s.io "role-liruilong" deleted┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl delete rolebindings rbind-liruilongrolebinding.rbac.authorization.k8s.io "rbind-liruilong" deleted删除集群角色、集群角色绑定
┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl delete ClusterRole role-liruilongclusterrole.rbac.authorization.k8s.io "role-liruilong" deleted┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$kubectl delete clusterrolebinding cbind-liruilongclusterrolebinding.rbac.authorization.k8s.io "cbind-liruilong" deleted┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-rbac-create]└─$关于Api Service的授权管理，还有很多内容，时间关系，先和小伙伴分享到这里，生活加油
