一、认证与授权
1. 访问控制概述
对于所有对外提供资源与服务的系统而言，认证与授权是保障访问安全的两大核心基础能力。其中认证（Authentication）负责校验访问者的真实身份，授权（Authorization）针对已通过身份校验的主体分配对应操作权限。Kubernetes采用插件化架构解耦认证、授权逻辑，支持灵活切换授权策略，主流授权插件包含下列几类：
Node：节点专用授权机制
ABAC：基于属性的访问控制
RBAC：基于角色访问控制，生产环境中最常用
Webhook：属于HTTP回调的外部访问控制
2. API Server
API Server作为Kubernetes集群的网关，是资源对象访问与管理的唯一入口。所有需要操作集群资源的组件，如kube-controller-manager、kube-scheduler、kubelet、kube-proxy等核心组件，CoreDNS等集群附加组件，以及kubectl命令行工具，都必须通过该网关实现集群的访问与管理。
各类客户端所有读取和变更集群状态的数据操作都需要经过API Server处理，API Server会对每一条请求执行合法性校验，包含身份认证、操作权限校验、资源配置规范校验。只有全部校验通过，才能够读取数据或将资源信息持久化存储至后端etcd数据库。
客户端身份认证由API Server配置的一个或多个认证插件实现。当收到访问请求时，API Server会按顺序依次调用认证插件校验客户端身份，直至某一个插件成功识别请求者身份。
授权流程同样依托一组授权插件执行，授权插件用于判断已通过认证的 用户是否具备对应资源操作权限。例如，创建、查询、删除资源等。完成授权校验后，合法请求还需要经过一个或多个准入控制插件进行预处理和合规检测。例如，校验目标命名空间是否存在，核查资源配置是否超出配额限制等。任意一项准入检查不通过，都会直接拒绝本次操作。
3. User、Permission和Role
用户（User）是能够独立访问计算机系统资源或数据的主体（Subject）。许可（Permission）定义了可针对一个或多个客体（Object）执行的操作（Action）。
角色（Role）代表一组权限集合，由多条许可组成构成。
一个用户可被授予多个角色，每个角色包含多条许可。同一条许可也可分配给多个角色，一项操作能够作用于多个客体，一个客体同样支持多种操作。
RBAC以角色为核心载体完成权限分配，通过为账户绑定一个或多个角色，是账号获得对应角色内置的全部权限。这里的账号可以是普通用户、用户组、服务账户以及对应的用户组。当账号关联多个角色时，其最终权限为所有角色权限的并集。
二、UserAccount和ServiceAccount
1. 用户与用户组
在Kubernetes中，客户端访问API Server主要有三种方式：kubectl命令行、客户端库、直接调用REST接口。能够发起访问请求的主体（Subject）分为两大类：
User Account（用户账号）：由Kubernetes外部独立系统进行管理，集群不存在表示此类用户账户的对象。作用范围为整个集群，账户名称要求全局唯一。
Service Account（服务账号）：专供Pod内进程访问Kubernetes API使用，隶属于特定命名空间，权限访问仅限于当前命名空间。可由APi Server自动创建或手动通过API创建，配套由Secret类型凭证，用于Pod身份认证。
两类账户均可归属于一个或多个用户组，用户组自身不具备操作权限，但组上绑定的权限能够被组内所有账户继承，以此简化集群授权管理。
2. User Account创建
[Step1] 新建一个用户，在专用目录下为用户生成私钥文件。
root@k8s-master:~# useradd mike
root@k8s-master:~# passwd mike
New password:mike@123
Retype new password:mike@123
root@k8s-master:~# cd /etc/kubernetes/pki/
root@k8s-master:/etc/kubernetes/pki# openssl genrsa -out mike.keyopenssl genrsa：生成RSA非对称私钥
-out mike.key：将生成的私钥输出保存至mike.key文件
[Step2] 使用OpenSSL生成随机数据，并写入/root/.rnd文件，用于补充OpenSSL的随机熵源。因为早期OpenSSL在系统熵不足时，会依赖“.rnd”文件保存随机种子。如果缺失该文件，执行证书相关命令可能出现随机生成数报错，执行这条命令相当于手动初始化/刷行随机种子文件。现代Linux依靠“/dev/urandom”，一般不再需要强制读取“.rnd”，部分旧版本环境生成证书前执行该命令规避随机数异常。
root@k8s-master:/etc/kubernetes/pki# openssl rand -writerand /root/.rnd[Step3] 用私钥创建一个证书签名请求（CSR文件），需要在subject中携带用户信息。
root@k8s-master:/etc/kubernetes/pki# openssl req -new -key mike.key -out mike.csr -subj "/CN=mike/O=kubernetes"openssl req：OpenSSL证书请求管理工具
-new：新建证书签名请求
-key mike.key：指定RSA私钥文件
-out mike.csr：输出证书请求文件
-subj：指定证书主体信息
/CN=mike：CommonName，Kubernetes将其识别为访问API Server的用户名
/O=kubernetes：Organization，Kubernetes识别为用户所属用户组
[Step4] 使用集群CA证书对上述申请的CSR证书签名请求进行签发，生成用户客户端证书。
root@k8s-master:/etc/kubernetes/pki# openssl x509 -req -in mike.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out mike.crt -days 365openssl x509：OpenSSL处理X509格式证书的根据，可实现证书签发、查看信息
-req：表示本次操作输入文件的证书签名请求
-in mike.csr：指定待签名的证书请求文件
-CA ca.crt：指定根CA公钥证书
-CAkey ca.key：指定CA的私钥，使用该私钥完成签名
-CAcreateserial：自动生成ca.serial序列号文件，记录下一张证书编号
-out mike.crt：输出签发完成的证书文件
-days 365：设置证书有效时长
[Step5] 如果要以mike身份使用kubectl管理集群，需要将tom的身份认证信息写入kubectl客户端配置，配置文件可选用“/etc/kubernetes/admin.conf”或“~/.kube/config”。
root@k8s-master:/etc/kubernetes/pki# kubectl config set-credentials mike \
> --client-certificate=mike.crt \
> --client-key=mike.key
[Step6] 配置context上下文，绑定集群（cluster）和用户凭证（credentials），后续可通过切换上下文命令，使用mike账号管理对应的集群。
root@k8s-master:/etc/kubernetes/pki# kubectl config set-context mike@cka --cluster=cka --user=mike
[Step7] 验证：切换至mike用户上下文访问集群，查看当前命名空间下所有的Pod。此时会返回错误信息，原因是尚未为mike配置RBAC访问授权。
root@k8s-master:/etc/kubernetes/pki# kubectl config use-context mike@cka
root@k8s-master:/etc/kubernetes/pki# kubectl get pods
3. Service Account概述
日常运维场景中，UserAccount使用频次较低，使用和操作更多的是ServiceAccount。ServiceAccount是为了方便Pod内进程调用Kubernetes API或外部服务设计，它与UserAccount存在以下区别：
UserAccount是为人设计的，ServiceAccount面向Pod内程序访问Kubernetes API而设计的；
UserAccount作用域横跨所有命名空间，ServiceAccount仅生效于自身所属命名空间；
每个命名空间会自动创建一个名为“default”的ServiceAccount；
Token控制器监测ServiceAccount的创建事件，并自动为其生成对应的Secret。
开启ServiceAccount准入控制器后，创建Pod时遵循以下规则：
每个Pod都关联一个ServiceAccount，ServiceAccount用于定义Pod访问集群内部资源的权限范围。创建Pod时如果未显式指定，“spec.serviceAccountName”会默认赋值为default；
系统会校验引用的ServiceAccount是否存在，如果不存在则拒绝创建Pod；
若Pod未配置ImagePullSecret，会自动将ServiceAccount的ImagePullSecret注入Pod；
容器启动时，ServiceAccount对应的Token与ca.crt证书会自动挂载至容器内路径“/var/run/secrets/kubernetes.io/serviceaccount”
4. ServiceAccount创建
[Step1] 本地新建一个命名空间。
root@k8s-master:~# kubectl create namespace sanamespace[Step2] 本地新建YAML清单，定义ServiceAccount资源描述模板。
root@k8s-master:~# vim service-account.yml
# 写入下列内容
apiVersion: v1 # 固定配置
kind: ServiceAccount # 资源类型
metadata:
name: service-account
namespace: sanamespace[Step3] 基于YAML清单向Kubernetes集群声明式地创建ServiceAccount资源。
root@k8s-master:~# kubectl create -f service-account.yml[Step4] 验证：查看sanamespace命名空间下所有的ServiceAccount资源，能够看到手动创建的服务账号。同时列表中还存在名为default的ServiceAccount。default服务账号无需手动创建，属于集群自动管理资源。每当创建新命名空间时，ServiceAccount控制器会自动在该命名空间生成default服务账号。
root@k8s-master:~# kubectl get -n sanamespace serviceaccounts
5. ServiceAccount默认指派
[Step1] 本地新建YAML清单，定义Pod资源描述模板。
root@k8s-master:~# vim default-service-account.yml
# 写入下列内容
apiVersion: v1 # 固定配置
kind: Pod # 资源类型
metadata:
name: default-service-account
spec:
containers:
- name: default-service-account
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["sleep","1000"][Step2] 根据YAML文件向Kubernetes集群声明式地创建Pod资源。
root@k8s-master:~# kubectl create -f default-service-account.yml[Step3] 验证：基于文件内定义的资源清单，查询集群中该资源的运行状态与基础信息。
root@k8s-master:~# kubectl get -f default-service-account.yml
[Step4] 验证：查询当前命名空间中default-service-account对应Pod的配置信息，筛选出其中serviceAccountName字段。可以看到，若创建Pod时未手动指定ServiceAccount，系统会自动分配当前命名空间内的default服务账号，serviceAccountName代表Pod用于和API Server通信的服务账户名称。
root@k8s-master:~# kubectl get pods default-service-account -o yaml | grep serviceAccount: -A 1
6. Token Secret
每个命名空间内置名称default的ServiceAccount，ServiceAccount配套存在用于与API Server交互的授权凭证。该凭证通常称为Token，Token文件的内容一般是证书或密码。以Secret资源形式存储，内容本质为身份令牌。
[Step1] 查看sanamespace命名空间下ServiceAccount。
root@k8s-master:~# kubectl -n sanamespace get serviceaccounts
[Step2] 查看当前命名空间的Secret资源，可以看到为空。这是因为Kubernetes1.24及以上版本默认不再为ServiceAccount生成关联Token Secret，因此当前看不到对应的令牌Secret。
root@k8s-master:~# kubectl -n sanamespace get secrets
三、RBAC插件
1. RBAC概述
Kubernetes通过RBAC机制实现授权，RBAC全称基于角色的访问控制（Role-Based Access Control）。
主体（subject）：代表操作者，用来定义谁能、谁不能操作哪些资源对象。
操作（verb）：代表要执行的动作，常见有创建、删除、修改、查询（create、delete、update、patch、get、list等）
客体（object）：被操作的对象，在k8s中就是各类资源以及对应的API访问路径。
2. Role与ClusterRole
RBAC授权插件支持Role和ClusterRole两类角色资源，二者均为Kubernetes标准API对象。RBAC中的Role或ClusterRole由一组权限规则组成，权限策略仅做累加生效，不存在显式拒绝操作的规则。
Role：作用域为命名空间级别，用来定义单个命名空间内部的资源访问权限。
ClusterRole：作用域为集群级别，可用于集群范围资源的权限定义。
如果需要在命名空间内定义角色，应该使用Role；如果希望定义集群访问的角色，应该使用ClusterRole。
3. ClusterRole与ClusterRoleBinding
角色绑定（Role Binding）的作用是将角色定义好的权限分配给一个或多个身份主体。绑定配置中记录了需要授权的主体（User、Group、ServiceAccount），同时引用要分配的角色。RoleBinding只在自身所在命名空间生效授权，ClusterRoleBinding则作用于整个集群，权限在所有命名空间有效。
3.1 RoleBinding一共有两种使用方式：
绑定同一命名空间内的Role；
引用集群级别的ClusterRole，并且会将ClusterRole的权限限制在当前RoleBinding所在命名空间内使用。
3.2 ClusterRoleBinding、RoleBinding、ClusterRole、Role四种对象组件的关系如图所示：
Role与RoleBinding限定在独立命名空间，ClusterRole与ClusterRoleBinding作用于整个集群。
RoleBinding只能绑定同一命名空间的Role，但是也可以引用ClusterRole。
ClusterRoleBinding仅能绑定ClusterRole。
4. 内置的ClusterRole
Kubernetes内置4个预定义的ClusterRole，可以直接拿来使用。熟练掌握这些内置集群角色，有助于快速创建用户并完成权限配置。
cluster-admin：集群最高权限，慎用；
admin：多数资源管理权限，无Node操作权限；
edit：拥有多数资源的修改权限；
view：仅拥有大部分资源的只读查询权限。
[Step1] 查看集群中所有ClusterRole集群角色资源，其中名称以“system:”开头的均为系统预配置角色。
root@k8s-master:~# kubectl get clusterroles.rbac.authorization.k8s.io
[Step2] 查看当前集群内所有ClusterRoleBinding集群角色绑定资源，名称以“system:”开头的条目为系统预先配置的绑定资源。
root@k8s-master:~# kubectl get clusterrolebindings.rbac.authorization.k8s.io
[Step3] 系统预置的ClusterRole主要供Kubernetes内部组件的ServiceAccount绑定使用，使用命令查看cluster-admin角色详情可以看到。
root@k8s-master:~# kubectl describe clusterrole cluster-admin
四、RBAC的可选参数
1. 可选verbs操作权限
5.1 常用verbs操作权限
5.2 注意事项
get ≠ list，get查询一条资源，list查询一类资源。
update需要提交完整资源，patch支持局部修改
deletecollection批量清空资源，和单独delete不同
[Examples] 典型只读权限配置。
verbs: ["get","list","watch"]2. 可选主体类型
在RoleBinding和ClusterRoleBinding的subjects中，Kind一共存在三种主体类型。
3. 角色可用资源类型
3.1 resources参数支持多种写法
仅资源名：核心API组，apiGroups:[“”]，如pods、services
资源.组名：指定API分组，如 deployment.apps、ingresses.networking.k8s.io
资源/子资源：如 pods/log、pods/status
多资源使用逗号分隔：如【pods,configmaps,deployments.apps】
3.2 角色常用资源范围
五、Role与RoleBinding案例配置
1. 命令行方式配置普通用户访问权限
[Step1] 新建命名空间，名称为rolespace。
root@k8s-master:~# kubectl create namespace rolespace[Step2] 在rolespace命名空间内创建角色role01，针对Pod资源授予标准只读权限。
root@k8s-master:~# kubectl create role role01 \
> --verb="get,watch,list" \
> --resource="pods" \
> -n rolespace--verb="get,watch,list"：允许执行的权限，分别为查询单个Pod、实时监听Pod变更、列出全部Pod
--resource="pods"：权限生效的资源类型为Pods
-n rolespace：指定命名空间为rolespace
[Step3] 验证：查看rolespace命名空间下名为role01的Role资源详细配置与权限规则。
root@k8s-master:~# kubectl -n rolespace describe role/role01
[Step4] 在role-namespace命名空间创建角色绑定role01_binding，绑定role01角色，授权给用户urole01。
root@k8s-master:~# kubectl create rolebinding role01_binding \
> --role=role01 \
> --user=urole01 \
> -n rolespace--role=role01：引用同一命名空间下名为role01的角色
--user=urole01：授权主体为用户urole01
-n rolespace：指定命名空间为role01_binding
[Step5] 验证：查看rolespace命名空间下role01_binding的详细信息。
root@k8s-master:~# kubectl describe -n rolespace rolebindings/role01_binding
[Step6] 模拟rolespace命名空间下普通用户urole01身份，校验是否具备创建Pod的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth -n rolespace can-i create pods --as=urole01auth：kubectl子命令，权限认证操作入口
can-i：权限预检工具，用于查询某个主体是否具备对应操作权限，仅检测，不会执行真实资源操作
--as=urole01：直接填写用户名，普通用户无需添加“system:serviceaccount:命名空间:服务账号名”
[Step7] 模拟rolespace命名空间下普通用户urole01身份，校验是否具备读取Pod的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get pods --as=urole01
[Step8] 模拟rolespace命名空间下普通用户urole01身份，校验是否具备读取Deployment的权限。可以看到回显值为“no”，说明当前账号不具备读取其他类型资源的权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get deployments --as=urole01
2. YAML方式配置普通用户访问权限
[Step1] 本地新建YAML清单，定义Role资源描述模板。在rolespace命名空间内创建角色role02，针对Pod资源授予标准只读权限。
root@k8s-master:~# vim role02.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: Role # 资源类型
metadata:
name: role02
namespace: rolespace
rules: # 权限规则
- apiGroups: [""] # 对应/api/v1下的原生资源（Pod、Service、ConfigMap等）
resources: ["pods"] # 授权的资源类型
verbs: ["get","watch","list"] # 拥有的权限[Step2] 基于YAML清单向Kubernetes集群声明式地创建Role资源。
root@k8s-master:~# kubectl create -f role02.yml[Step3] 验证：查看rolespace命名空间下名为role02的Role资源详细配置与权限规则。
root@k8s-master:~# kubectl describe -n rolespace role/role02
[Step4] 本地新建YAML清单，定义RoleBinding资源描述模板。在rolespace命名空间创建角色绑定role02_binding，绑定role02角色，授权给用户urole02。
root@k8s-master:~# vim role02_binding.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: RoleBinding # 资源类型
metadata:
creationTimestamp: null # 部署到集群后由集群自动填充创建时间
name: role02_binding
namespace: rolespace
roleRef: # 角色引用
apiGroup: rbac.authorization.k8s.io # RBAC授权组
kind: Role # 引用同命名空间内的Role资源
name: role02 # 目标角色为role02
subjects: # 主体
- apiGroup: rbac.authorization.k8s.io # RBAC授权组
kind: User # 主体类型为用户
name: urole02 # 授权给用户urole02[Step5] 基于YAML清单向Kubernetes集群声明式地创建RoleBinding资源。
root@k8s-master:~# kubectl create -f role02_binding.yml[Step6] 验证：查看rolespace命名空间下role02_binding的详细信息。
root@k8s-master:~# kubectl describe -n rolespace rolebindings/role02_binding
[Step7] 模拟rolespace命名空间下普通用户urole02身份，校验是否具备创建Pod的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth -n rolespace can-i create pods --as=urole02
[Step8] 模拟rolespace命名空间下普通用户urole02身份，校验是否具备读取Pod的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get pods --as=urole02
[Step9] 模拟rolespace命名空间下普通用户urole02身份，校验是否具备读取Deployment的权限。可以看到回显值为“yes”，说明当前账号不具备读取其他类型资源的权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get deployments --as=urole02
3. 命令行方式配置ServiceAccount访问权限
[Step1] 在rolespace命名空间内创建角色role03，针对Pod资源授予标准只读权限。
root@k8s-master:~# kubectl create role role03 \
> --verb="get,watch,list" \
> --resource="pods" \
> -n rolespace--verb="get,watch,list"：允许执行的权限，分别为查询单个Pod、实时监听Pod变更、列出全部Pod
--resource="pods"：权限生效的资源类型为Pods
-n rolespace：指定命名空间为rolespace
[Step2] 验证：查看rolespace命名空间下名为role03的Role资源详细配置与权限规则。
root@k8s-master:~# kubectl describe -n rolespace role/role03
[Step3] 在rolespace命名空间创建角色绑定role03_binding，关联角色role03，将权限授予rolespace命名空间内名称为sarole03的ServiceAccount。
oot@k8s-master:~# kubectl create rolebinding role03_binding \
> --role=role03 \
> --serviceaccount=rolespace:sarole03 \
> -n rolespace--role=role03：引用同一命名空间下名为role03的角色
--serviceaccount=rolespace:sarole03：授权主体为rolespace命名空间下的sarole03服务账号
-n rolespace：指定命名空间rolespace
[Step4] 验证：查看rolespace命名空间下role03_binding的详细信息。
root@k8s-master:~# kubectl describe -n rolespace rolebindings/role03_binding
[Step5] 模拟rolespace命名空间下sarole03服务账号身份，校验该账号是否具备创建Pod资源的权限。可以看到回显值为“no”，说明当前账号不具备创建权限。
root@k8s-master:~# kubectl auth -n rolespace can-i create pods \
> --as=system:serviceaccount:rolespace:sarole03auth：kubectl子命令，权限认证操作入口
can-i：权限预检工具，用于查询某个主体是否具备对应操作权限，仅检测，不会执行真实资源操作
--as=system:serviceaccount:rolespace:sarole03：模拟身份参数，使用指定主体身份发起权限检查
字符串格式规范：system:serviceaccount:<命名空间>:<服务账号名称>
system:serviceaccount：固定前缀，标识身份类型为服务账号
[Step6] 模拟rolespace命名空间下sarole03服务账号身份，校验该账号是否具备读取Pod资源的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get pods \
> --as=system:serviceaccount:rolespace:sarole03
[Step7] 模拟rolespace命名空间下sarole03服务账号身份，校验该账号是否具备读取Deployment资源的权限。可以看到回显值为“no”，说明当前账号不具备读取其它类型资源的权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get deployments \
> --as=system:serviceaccount:rolespace:sarole03
4. YAML方式配置ServiceAccount访问权限
[Step1] 本地新建YAML清单，定义Role资源描述模板。在rolespace命名空间内创建角色role04，针对Pod资源授予标准只读权限。
root@k8s-master:~# vim role04.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: Role # 资源类型
metadata:
name: role04
namespace: rolespace
rules: # 权限规则
- apiGroups: [""] # 对应/api/v1下的原生资源（Pod、Service、ConfigMap等）
resources: ["pods"] # 授权的资源类型
verbs: ["get","watch","list"] # 授予的权限[Step2] 基于YAML清单向Kubernetes集群声明式地创建Role资源。
root@k8s-master:~# kubectl create -f role04.yml[Step3] 验证：查看rolespace命名空间下名为role04的Role资源详细配置与权限规则。
root@k8s-master:~# kubectl describe -n rolespace role/role04
[Step4] 本地新建YAML清单，定义RoleBinding资源描述模板。在rolespace命名空间创建角色绑定role04_binding，关联角色role04，将权限授予rolespace命名空间内名称为sarole04的ServiceAccount。
root@k8s-master:~# vim role04_binding.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: RoleBinding # 资源类型
metadata:
name: role04_binding # 部署到集群后由集群自动填充创建时间
namespace: rolespace
roleRef: # 角色引用
apiGroup: rbac.authorization.k8s.io # RBAC授权组
kind: Role # 引用同命名空间内的Role资源
name: role04 # 目标角色为role04
subjects: # 主体
- kind: ServiceAccount # 主体类型为ServiceAccount
name: sarole04 # 服务账号名称
namespace: rolespace # 命名空间[Step5] 基于YAML清单向Kubernetes集群声明式地创建RoleBinding资源。
root@k8s-master:~# kubectl create -f role04_binding.yml[Step6] 验证：查看rolespace命名空间下名为role04_binding的RoleBinding资源详细信息。
root@k8s-master:~# kubectl describe -n rolespace rolebindings/role04_binding
[Step7] 模拟rolespace命名空间下sarole04服务账号身份，校验该账号是否具备创建Pod资源的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth -n rolespace can-i create pods \
> --as=system:serviceaccount:rolespace:sarole04
[Step8] 在模拟rolespace命名空间下sarole04服务账号身份，校验该账号是否具备读取Pod资源的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get pods \
> --as=system:serviceaccount:rolespace:sarole04
[Step9] 模拟rolespace命名空间下sarole04服务账号身份，校验该账号是否具备读取Deployment资源的权限。可以看到回显值为“no”，说明当前账号不具备读取其它类型资源的权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get deployments \
> --as=system:serviceaccount:rolespace:sarole04
六、ClusterRole和ClusterRoleBinding案例配置
1. 命令行方式配置普通用户访问权限
[Step1] 在集群中创建集群角色cluster_role01，对Pod资源授予标准只读权限。
root@k8s-master:~# kubectl create clusterrole cluster_role01 \
> --verb="get,watch,list" \
> --resource="pods"--verb="get,watch,list"：允许执行的权限，分别为查询单个Pod、实时监听Pod变更、列出全部Pod
--resource="pods"：权限生效的资源类型为Pods
[Step2] 验证：查看当前集群中名为cluster_role01的ClusterRole资源详细配置与权限规则。
root@k8s-master:~# kubectl describe clusterrole/cluster_role01
[Step3] 在集群中创建集群角色绑定cluster_role01_binding，关联集群角色cluster_role01，将对应权限授予用户crole01。
root@k8s-master:~# kubectl create clusterrolebinding cluster_role01_binding \
> --clusterrole=cluster_role01 \
> --user=crole01--clusterrole=cluster_role01：引用集群角色cluster_role01
--user=crole01：授权主体为用户crole01
[Step4] 验证：查看当前集群中名为cluster_role01_binding的ClusterRoleBinding资源详细信息。
root@k8s-master:~# kubectl describe clusterrolebinding/cluster_role01_binding
[Step5] 模拟普通用户crole01身份，校验是否具备创建Pod的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth can-i create pods --as=crole01
[Step6] 模拟普通用户crole01身份，校验是否具备读取Pod的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth can-i get pods --as=crole01
[Step7] 模拟普通用户crole01身份，校验是否具备读取Deployment的权限。可以看到回显值为“yes”，说明当前账号不具备读取其他类型资源的权限。
root@k8s-master:~# kubectl auth can-i get deployments --as=crole01
2. YAML方式配置普通用户访问权限
编写ClusterRole资源的YAML清单时，权限相关配置参数与Role基本一致。
但是ClusterRole属于集群级别资源，不隶属于任何命名空间，因此元数据中无需配置metadata.namespace字段。
[Step1] 本地新建YAML清单，定义ClusterRole资源描述模板。在集群中创建集群角色cluster_role02，对Pod资源授予标准只读权限。
root@k8s-master:~# vim cluster_role02.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: ClusterRole # 资源类型
metadata:
name: cluster_role02
rules: # 权限规则列表
- apiGroups: [""] # 对应/api/v1下的原生资源（Pod、Service、ConfigMap等）
resources: ["pods"] # 管控资源对象为Pod
verbs: ["get","watch","list"] # 拥有的权限[Step2] 基于YAML清单向Kubernetes集群声明式地创建ClusterRole资源。
root@k8s-master:~# kubectl create -f cluster_role02.yml[Step3] 验证：查看当前集群下名为cluster_role02的ClusterRole资源详细配置与权限规则。
root@k8s-master:~# kubectl describe clusterrole/cluster_role02
[Step4] 本地新建YAML清单，定义ClusterRoleBinding资源描述模板。在集群中创建集群角色绑定cluster-role-binding2，关联集群角色cluster-role02，将对应权限授予用户crole02。
root@k8s-master:~# vim cluster_role02_binding.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: ClusterRoleBinding # 资源类型
metadata:
creationTimestamp: null # 部署到集群后由集群自动填充创建时间
name: cluster_role02_binding
roleRef: # 角色引用
apiGroup: rbac.authorization.k8s.io # RBAC授权组
kind: ClusterRole # 引用同命名空间内的ClusterRole资源
name: cluster_role02 # 关联角色cluster-role02
subjects: # 主体
- apiGroup: rbac.authorization.k8s.io # RBAC授权组
kind: User # 主体类型为用户
name: crole02 # 用户名[Step5] 基于YAML清单向Kubernetes集群声明式地创建ClusterRoleBinding资源。
root@k8s-master:~# kubectl create -f cluster_role02_binding.yml[Step6] 验证：查看当前集群中名为cluster_role02_binding的ClusterRoleBinding资源详细信息。
root@k8s-master:~# kubectl describe clusterrolebindings/cluster_role02_binding
[Step7] 模拟普通用户crole02身份，校验是否具备创建Pod的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth can-i create pods --as=crole02
[Step8] 模拟普通用户crole02身份，校验是否具备读取Pod的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth can-i get pods --as=crole02
[Step9] 模拟普通用户crole02身份，校验是否具备读取Deployment的权限。可以看到回显值为“yes”，说明当前账号不具备读取其他类型资源的权限。
root@k8s-master:~# kubectl auth can-i get deployments --as=crole02
3. 命令行方式配置ServiceAccount访问权限
[Step1] 在集群内创建角色cluster_role03，针对Pod资源授予标准只读权限。
root@k8s-master:~# kubectl create clusterrole cluster_role03 \
> --verb="get,watch,list" \
> --resource="pods"--verb="get,watch,list"：允许执行的权限，分别为查询单个Pod、实时监听Pod变更、列出全部Pod
--resource="pods"：权限生效的资源类型为Pods
[Step2] 验证：查看当前集群中名为cluster_role03的ClusterRole资源详细配置与权限规则。
root@k8s-master:~# kubectl describe clusterrole/cluster_role03
[Step3] 在集群中创建集群角色绑定cluster_role03_binding，关联集群角色cluster_role03，将对应权限授予rolespace命名空间下的服务账号crole03。
root@k8s-master:~# kubectl create clusterrolebinding cluster_role03_binding \
> --clusterrole=cluster_role03 \
> --serviceaccount=rolespace:crole03[Step4] 验证：查看当前集群中名为cluster_role03_binding的ClusterRoleBinding资源详细信息。
root@k8s-master:~# kubectl describe clusterrolebindings/cluster_role03_binding
[Step5] 模拟rolespace命名空间下crole03服务账号身份，校验该账号是否具备创建pod资源的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth can-i create pods \
> --as=system:serviceaccount:rolespace:crole03
[Step6] 模拟rolespace命名空间下crole03服务账号身份，校验该账号是否具备创建pod资源的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth can-i get pods \
> --as=system:serviceaccount:rolespace:crole03
[Step7] 模拟rolespace命名空间下crole03服务账号身份，校验是否具备读取Deployment的权限。可以看到回显值为“yes”，说明当前账号不具备读取其他类型资源的权限。
root@k8s-master:~# kubectl auth can-i get deployments \
> --as=system:serviceaccount:rolespace:crole03
4. YAML方式配置ServiceAccount访问权限
[Step1] 本地新建YAML清单，定义ClusterRole资源描述模板。在集群中创建集群角色cluster_role04，对Pod资源授予标准只读权限。
root@k8s-master:~# vim cluster_role04.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: ClusterRole # 资源类型
metadata:
name: cluster_role04
rules: # 权限规则
- apiGroups: [""] # 对应/api/v1下的原生资源（Pod、Service、ConfigMap等）
resources: ["pods"] # 授权的资源类型
verbs: ["get","watch","list"] # 授予的权限[Step2] 基于YAML清单向Kubernetes集群声明式地创建ClusterRole资源。
root@k8s-master:~# kubectl create -f cluster_role04.yml[Step3] 验证：查看当前集群下名为cluster_role04的ClusterRole资源详细配置与权限规则。
root@k8s-master:~# kubectl describe clusterrole/cluster_role04
[Step4] 本地新建YAML清单，定义ClusterRoleBinding资源描述模板。在集群中创建集群角色绑定cluster_role04_binding，关联集群角色cluster_role04，授权对象为rolespace命名空间内的ServiceAccount
root@k8s-master:~# vim cluster_role04_binding.yml
# 写入下列内容
apiVersion: rbac.authorization.k8s.io/v1 # 版本信息
kind: ClusterRoleBinding # 资源类型
metadata:
name: cluster_role04_binding
roleRef: # 角色引用
apiGroup: rbac.authorization.k8s.io # RBAC授权组
kind: ClusterRole # 引用同命名空间内的Role资源
name: cluster_role04 # 目标角色为cluster_role04
subjects: # 主体
- kind: ServiceAccount # 主体类型为ServiceAccount
name: sarole04 # 服务账号名称
namespace: rolespace # 命名空间[Step5] 基于YAML清单向Kubernetes集群声明式地创建ClusterRoleBinding资源。
root@k8s-master:~# kubectl create -f cluster_role04_binding.yml[Step6] 验证：查看当前集群中名为cluster_role04_binding的ClusterRoleBinding资源详细信息。
root@k8s-master:~# kubectl describe clusterrolebindings/cluster_role04_binding
[Step7] 模拟rolespace命名空间下crole04服务账号身份，校验是否具备创建Pod的权限。可以看到回显值为“no”，说明当前账号不具备对应权限。
root@k8s-master:~# kubectl auth -n rolespace can-i create pods \
> --as=system:serviceaccount:rolespace:sarole04
[Step8] 模拟rolespace命名空间下crole04服务账号身份，校验是否具备读取Pod的权限。可以看到回显值为“yes”，说明当前账号具备读取权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get pods \
> --as=system:serviceaccount:rolespace:sarole04
[Step9] 模拟rolespace命名空间下crole04服务账号身份，校验是否具备读取Deployment的权限。可以看到回显值为“yes”，说明当前账号不具备读取其他类型资源的权限。
root@k8s-master:~# kubectl auth -n rolespace can-i get deployments \
> --as=system:serviceaccount:rolespace:sarole04
[Step10] 在当前环境下，虽然ClusterRole具备集群范围Pod读取权限。但是如果权限测试不指定命名空间时，默认访问default命名空间。而sarole04服务账号仅能访问rolespace命名空间内Pod，访问default命名空间内Pod会校验不通过。
root@k8s-master:~# kubectl auth can-i get pods --as=system:serviceaccount:rolespace:sarole04
