K8S RBAC 鉴权

介绍

K8S(Kubernetes)的RBAC(Role-Based Access Control,基于角色的访问控制)是一种权限控制机制,它允许管理员通过定义角色来限制用户对集群资源的访问权限。RBAC是Kubernetes中一个核心的授权策略,通过它,管理员可以实施精细化的权限管理,确保只有经过授权的用户或用户组才能执行特定的操作。

RBAC在Kubernetes中主要由四个关键组件构成:Role、ClusterRole、RoleBinding和ClusterRoleBinding。

  • Role:用于定义对命名空间内资源的访问权限。Role只能用于授予对某个特定命名空间中资源的访问权限。
  • ClusterRole:与Role类似,但用于定义对集群范围内资源的访问权限。ClusterRole可以授予对集群中所有命名空间的资源或非资源端点的访问权限。
  • RoleBinding:用于将Role绑定到一个或多个用户、服务账户或用户组,从而控制这些实体对命名空间内资源的访问。
  • ClusterRoleBinding:用于将ClusterRole绑定到一个或多个用户、服务账户或用户组,控制这些实体对集群范围内资源的访问。

使用RBAC时,管理员可以定义角色,并为这些角色分配适当的权限。然后,通过RoleBinding或ClusterRoleBinding将角色绑定到特定的用户或用户组。这样,用户只能执行其角色所允许的操作,而无法访问或修改未授权的资源。

Role 和 ClusterRole

Role 举例

下面是一个位于 “default” 名字空间的 Role 的示例,可用来授予对 Pod 的读访问权限:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

字段解释

  • apiVersion 指定了 Kubernetes API 的版本,这里是 rbac.authorization.k8s.io/v1,表示使用了 Kubernetes 的 RBAC API 版本
  • kind 指定了 Kubernetes 资源的类型,这里是 Role,表示定义了一个角色。
  • rules 指定了角色的权限规则。
  • apiGroups 指定了 API 组,这里是 [“”],表示核心 API 组。
  • resources 指定了资源类型,这里是 [“pods”],表示 Pods 资源。
  • verbs 指定了允许的操作,这里是 [“get”, “watch”, “list”],表示允许执行 get、watch 和 list 操作。

apiGroups 介绍

核心 API 组:

  • pods: Pod 是 Kubernetes 中最小的可部署对象,代表集群中的一个运行中的应用程序实例。
  • services: Service 定义了一组Pod的逻辑集合以及访问这些Pod的策略,通常用于创建应用程序的网络端点。
  • nodes: Node 是 Kubernetes 集群中的一个工作节点,可以是虚拟机或物理机器。
  • namespaces: Namespace 是 Kubernetes 中用于多租户的虚拟集群的一种方式。它允许将 Kubernetes 集群划分为多个虚拟集群,以便在同一集群中运行多个团队或用户的应用程序。
  • persistentvolumes: PersistentVolume(PV)是 Kubernetes 中的一种 API 对象,它抽象了存储系统,为用户提供了一种将存储挂载到 Pod 中的方式。
  • persistentvolumeclaims: PersistentVolumeClaim(PVC)是 Kubernetes 中的一种 API 对象,它是 Pod 中对存储资源的一种请求。

describe 查看

[root@master01 yaml]# kubectl describe role pod-reader 
Name:         pod-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get watch list]

apiGroups 组查看

kubectl api-resources --verbs list

列举几种用法

在 RBAC 角色表达子资源时,使用斜线(/)来分隔资源和子资源。 要允许某主体读取 pods 同时访问这些 Pod 的 log 子资源,可以这样写:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
<think>嗯,用户让我了解Kubernetes的认证和原理和方法。首先,我需要回顾之前提供的几个引用内容。引用[1]提到sa.key和sa.pub这对密钥用于Service Account,kube-controller-manager使用私钥签名token,而master节点用公钥验证。这里涉及的是Service Account的认证机制,特别是Pod如何通过token与API Server交互。 引用[2]是一系列K8s面试题,其中提到了RBAC、Secret的使用、PodSecurityPolicy等安全机制。虽然问题列表较多,但重点是RBAC和准入控制部分,这些都属于的范畴。引用[3]提到所有操作都通过Kubernetes API,由API Server处理,这说明了认证和发生的环节。引用[4]可能包含深入原理,但链接无法访问,所以只能参考其他引用。 接下来需要整合这些信息。K8s的认证发生在API Server层,用户或Pod的请求需要先通过认证,然后。认证的方式可能有多种,比如客户端证书、Bearer Token(Service Account用的就是这种)、基本认证等。引用[1]详细说明了Service Account的流程:Pod挂载token,用sa.pub验证签名。这部分属于认证阶段。 然后是部分,引用[2]中提到的RBAC(基于角色的访问控制)应该是重点。RBAC通过Role和ClusterRole定义权限,再绑定到Subject(用户、组或Service Account)。此外,可能还有ABAC等其他机制,但RBAC是现在更常用的。另外,准入控制(Admission Control)在之后,用来修改或验证请求,比如PodSecurityPolicy(虽然在新版本中被弃用,但原理类似)。 还需考虑流程顺序:请求先认证身份,再检查是否有权限),最后通过准入控制器处理。例如,kube-proxy作为Pod运行时,使用Service Account的token认证,然后RBAC检查其是否有权限访问特定资源。 用户可能想知道整个流程如何串联,以及不同组件的作用。比如API Server如何处理请求,Controller Manager的角色,还有Service Account的生成过程(由API Server自动创建并挂载到Pod)。另外,Secret的作用在引用[2]中提到,用于保存敏感信息,如token或证书,这与Service Account有关联。 可能需要补充认证方式的多样性,比如X.509客户端证书、静态token文件等,但Service Account是集群内Pod的主要方式。部分除了RBAC,还应简要提及其他机制如Node,用于节点相关的权限管理。 最后,整体结构应分认证、、准入控制三部分,每个部分详细说明机制和例子。确保引用正确,比如引用[1]解释Service Account,引用[2]和[3]支持API Server的中心作用及RBAC的重要性。同时注意用户的问题可能涉及实际应用,如如何配置RBAC规则,或排查权限问题,但当前问题集中在原理,所以保持理论层面即可。 </think>以下是 Kubernetes 认证与的核心原理及关键机制,结合引用内容进行系统说明: --- ### **一、认证(Authentication)原理** **目标:** 验证用户/组件的身份 **发生位置:** API Server 接收请求的第一层 **核心方式:** 1. **X.509 客户端证书** - 用户或组件(如 `kubelet`)使用证书中的 `CN`(Common Name)作为用户名,`O`(Organization)作为用户组 - 证书由集群 CA(Certificate Authority)签发,API Server 用 CA 公钥验证签名 [^4] 2. **Service Account(服务账户)** - **原理:** - 每个 Namespace 自动创建默认 SA(如 `default`) - Pod 挂载 SA 的 `token`(JWT 令牌)和 `ca.crt` - `kube-controller-manager` 用私钥 `sa.key` 签名 token - API Server 用公钥 `sa.pub` 验证签名 [^1] - **示例:** ```yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: serviceAccountName: default # 使用默认SA containers: - name: nginx image: nginx ``` 3. **Bearer Token** - 静态令牌文件(较少用) - OpenID Connect(OIDC)集成企业身份系统 4. **基本认证(Basic Auth)** - 用户名/密码,通常不建议生产使用 --- ### **二、(Authorization)原理** **目标:** 检查已认证用户是否有权限执行操作 **核心机制:** 1. **RBAC(基于角色的访问控制)** - **核心对象:** - `Role`/`ClusterRole`:定义权限规则(如允许 `get pods`) - `RoleBinding`/`ClusterRoleBinding`:将角色绑定到用户/组/SA [^2] - **示例:** ```yaml # 创建角色(允许读取 default 命名空间的 Pod) kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] --- # 将角色绑定到 Service Account kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods namespace: default subjects: - kind: ServiceAccount name: default namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` 2. **ABAC(基于属性的访问控制)** - 通过策略文件定义复杂规则,维护困难,逐渐被 RBAC 取代 3. **Node Authorization(节点)** - 专门授 `kubelet` 访问节点相关资源(如自身 Pod 的 `bind`/`watch` 操作) 4. **Webhook** - 调用外部 REST 服务决策权限 --- ### **三、准入控制(Admission Control)** **目标:** 在后对请求进行修改或验证 **关键组件:** 1. **MutatingAdmissionWebhook** - 动态修改请求(如注入 Sidecar 容器) 2. **ValidatingAdmissionWebhook** - 验证请求合法性(如检查资源配额) 3. **PodSecurityPolicy(PSP)** - **作用:** 限制 Pod 的安全参数(如禁止特容器) - **注:** Kubernetes 1.25+ 已弃用 PSP,由 **Pod Security Admission** 替代 [^2] --- ### **四、关键流程示例** **Pod 访问 API Server 的完整流程:** 1. **认证:** Pod 使用 SA 的 JWT Token 向 API Server 发起请求 2. **:** RBAC 检查该 SA 是否具有所需权限 3. **准入控制:** Webhook 校验请求是否符合安全策略 4. **执行操作:** 通过所有检查后处理请求 --- ### **五、最佳实践** 1. **最小权限原则:** RoleBinding 限定必要权限 2. **定期轮换证书:** 包括 SA 密钥对(`sa.key`/`sa.pub`) [^1] 3. **审计日志:** 启用 `audit.k8s.io` API 记录访问事件 4. **替代 PSP:** 使用 `PodSecurity` 准入控制器(如 `restricted` 策略) ```yaml # Pod Security Admission 示例(Kubernetes 1.23+) apiVersion: v1 kind: Namespace metadata: name: secure-app labels: pod-security.kubernetes.io/enforce: restricted # 强制执行受限策略 ``` --- ### **相关问题** 1. 如何排查 Kubernetes API 访问权限被拒绝(403错误)? 2. Service Account 的 Token 如何实现自动更新? 3. RBAC 中 `Role` 和 `ClusterRole` 的应用场景有何区别? 4. 如何集成 Kubernetes 与企业级 LDAP/AD 认证系统? [^1]: SA 密钥对实现 Token 的签发与验证机制 [^2]: RBAC 和 PodSecurityPolicy 的安全控制逻辑 [^3]: 所有操作经由 API Server 的统一入口 [^4]: 证书体系在集群安全中的基础作用
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值