体验K8S的x509认证及RBAC授权机制

先让我们重温两个英文单词:authentication(认证)、authorization(授权)。

今天的实验目标:
1)基于X509证书方式来完成authentication(认证)。
2)基于RBAC方式来完成authorization(授权)

环境说明:

操作步骤:

第1步:生成Private key文件:

执行:

 

查看一下生成的Private key文件:

第2步: 使用私钥生成csr请求文件:

查看csr文件:

第3步:对csr文件进行base 64编码:

 

第4步:在kubernetes中创建CSR。

把下面的代码中的XXX替换成上面的base64编码,然后执行:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: XXX
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

 如下图:

 查看csr对象,这时为Pending状态:

第5步:对CSR进行签证(Approve)

签完后,状态变成:Approved, Issued。

查看CSR对象的详细:

第6步:把证书导出到myuser.crt文件。

 

 第7步:使用私钥文件和证书文件在k8s中创建一个用户,名为:myuser。

查看一下新创建的用户:

 第8步:创建角色(Role)对象,名称:developer。

 查看一下新创建的角色:

 可以看到,这个developer角色具有default namespace的POD的create, get, list, update, delete权限。

第9步:权限绑定

把myuser用户与developer角色绑定在一起,这样myuser就具有了developer角色的权限。

查看绑定详情:

 

第10步:验证(1)

1)验证myuser用户的读权限。

 2) 验证myuser用户的create权限

 第12步:验证(2)

删除绑定后,这个用户就没有权限了,报:forbidden。

 

 第13步:验证(3)

把用户也删除了,则报“not exist”

扩展:

创建用户后,在conifg文件中有myuser用户信息,包括:client-certificate-data和client-key-data。

其中client-certificate-data也就是上面第3步的csr经base 64位后的编码数据,也就是第4步创建CSR对象的Rqeuest 字段。

 另外,从上图可以看到,context(kubernetes-admin@kubernetes)仍只有一个。

 

<think>好的,我现在需要回答用户关于Kubernetes RBAC机制的例子说明。首先,用户之前已经询问过用户和组在K8S中的定义,现在希望了解RBAC的具体例子。我需要确保回答结构清晰,逐步说明,并符合之前的格式要求。 首先,我应该回顾RBAC的基本概念,然后通过具体示例来展示如何定义角色、绑定角色,以及如何应用到用户或服务账户上。可能需要分步骤,比如创建命名空间、角色、角色绑定,然后测试权限。 然后,考虑用户可能的背景。他们可能有一定的K8S基础,但需要具体例子来理解机制。因此,示例需要简洁明了,命令和YAML示例要准确,并且有解释每个部分的作用。 需要注意用户提到的系统级指令,比如使用正确的LaTeX格式,但用户的问题中没有数学表达式,可能不需要太多格式,但需要确保代码块正确。另外,回答要用中文,结构清晰,可能使用列表和分段。 可能需要包括Role和ClusterRole的区别,RoleBinding和ClusterRoleBinding的区别,以及如何通过kubectl auth can-i来验证权限。此外,服务账户的例子也是重要的,因为这是K8S中常用的权限管理方式。 需要检查是否有遗漏的关键点,比如内置的用户组或系统角色的引用,是否需要提到这些。同时,确保示例的步骤可行,用户能够按步骤操作并看到结果。 最后,总结RBAC的关键点,帮助用户记忆。避免使用复杂术语,保持解释简单易懂。确保每个示例都有明确的目的和结果说明,比如创建角色允许读取Pod,绑定到用户后,用户能够执行get命令但无法删除。</think>在 Kubernetes 中,**RBAC(基于角色的访问控制)** 通过 **Role**、**ClusterRole**、**RoleBinding** 和 **ClusterRoleBinding** 实现细粒度权限管理。下面通过具体场景演示其工作机制--- ### 场景 1:授权用户查看 Pod **目标**:允许用户 `alice` 在 `default` 命名空间中查看 Pod,但禁止其他操作。 #### 1. 创建 **Role**(定义权限范围) ```yaml # pod-reader-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default # 仅对 default 命名空间生效 name: pod-reader rules: - apiGroups: [""] # "" 表示核心 API 组(如 Pod) resources: ["pods"] # 控制访问的资源类型 verbs: ["get", "list"] # 允许的操作 ``` 应用配置: ```bash kubectl apply -f pod-reader-role.yaml ``` #### 2. 创建 **RoleBinding**(绑定权限) ```yaml # alice-pod-reader-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: alice-read-pods namespace: default subjects: - kind: User name: alice # 要授权的用户 apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader # 引用的 Role apiGroup: rbac.authorization.k8s.io ``` 应用配置: ```bash kubectl apply -f alice-pod-reader-binding.yaml ``` #### 3. 验证权限 ```bash # 切换为 alice 用户(需提前配置 kubeconfig) kubectl get pods -n default # 成功 kubectl delete pod mypod # 失败(无 delete 权限) ``` --- ### 场景 2:授权组管理全部命名空间 **目标**:允许 `dev-team` 组在所有命名空间中管理 Deployment。 #### 1. 创建 **ClusterRole**(集群级权限) ```yaml # deployment-admin-clusterrole.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: deployment-admin rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["*"] # 允许所有操作(create/delete/update等) ``` #### 2. 创建 **ClusterRoleBinding**(全局绑定) ```yaml # dev-team-deployment-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: dev-team-deployment-admin subjects: - kind: Group name: dev-team # 组名(通常由认证系统自动映射) apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: deployment-admin apiGroup: rbac.authorization.k8s.io ``` --- ### 场景 3:限制 ServiceAccount 权限 **目标**:仅允许 `monitoring-sa` 服务账户在 `monitoring` 命名空间中读取 Pod 日志。 #### 1. 创建 ServiceAccount ```bash kubectl create sa monitoring-sa -n monitoring ``` #### 2. 定义 Role ```yaml # pod-logs-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: monitoring name: pod-logs-reader rules: - apiGroups: [""] resources: ["pods/log"] # 指定子资源 verbs: ["get", "list"] ``` #### 3. 绑定权限 ```yaml # monitoring-sa-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: monitoring-sa-logs namespace: monitoring subjects: - kind: ServiceAccount name: monitoring-sa namespace: monitoring roleRef: kind: Role name: pod-logs-reader apiGroup: rbac.authorization.k8s.io ``` --- ### 权限验证工具 使用 `kubectl auth can-i` 快速检查权限: ```bash # 检查当前用户能否删除 default 命名空间的 Pod kubectl auth can-i delete pods -n default # 模拟特定用户的权限 kubectl auth can-i list pods --as=alice -n default ``` --- ### RBAC 核心组件对比 | 组件 | 作用域 | 典型用例 | |---------------------|-------------|------------------------------------------| | **Role** | 命名空间内 | 限制权限到单个命名空间(如管理 Pod) | | **ClusterRole** | 集群全局 | 跨命名空间操作(如查看节点、存储类) | | **RoleBinding** | 命名空间内 | 将 Role/ClusterRole 绑定到某命名空间的实体 | | **ClusterRoleBinding** | 集群全局 | 全局授权(如管理员权限) | --- ### 关键规则 1. **最小权限原则**:只授予必要权限 2. **优先使用 Role**:除非需要跨命名空间权限 3. **组优于用户**:通过组批量管理权限 4. **定期审计**:使用 `kubectl get rolebindings,clusterrolebindings` 检查授权
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值