Kubernetes 访问控制 - RBAC 鉴权

Author：rab

---

---

前言

API 访问控制有很多，比如 RBAC 鉴权、ABAC 鉴权、Node 鉴权等。自 Kubernetes 1.6 版本以后，RBAC 成为 Kubernetes 的默认访问控制机制。RBAC 允许管理员定义和控制哪些用户、服务账号或组可以执行哪些操作（例如创建、更新、删除、获取资源）以及对哪些资源。这有助于增加集群的安全性，并允许管理员实施细粒度的权限控制。Kubernetes 中的 Role-Based Access Control（RBAC）API 定义了四种主要对象 => Role（角色）、ClusterRole（集群角色）、RoleBinding（角色绑定）、ClusterRoleBinding（集群角色绑定），用于实现权限管理和访问控制策略。接下来，我们将分别介绍这 4 种对象资源。

RBAC 官网：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

一、Role

1、功能

Role 总是用来在某个名字空间内设置访问权限，在我们创建 Role 时，必须指定该 Role 所属的名字空间。

2、案例

apiVersion: rbac.authorization.k8s.io/v1
kind: Role                           # 定义了要创建的RBAC对象的类型，这里是一个Role对象
metadata:                            # Role对象的元信息
  namespace: default                 # 控制着该命名空间内的资源访问权限
  name: pod-reader                   # 后续的配置中引用该名称来分配权限
rules:                               # Role对象对象包含的权限规则
- apiGroups: [""]                    # 空字符串""表示控制核心API组，即不属于任何自定义API组的资源。这意味着该Role控制对核心Kubernetes资源的访问
  resources: ["pods"]                # 指定了要控制的资源类型，即 "pods"（Pod资源）
  verbs: ["get", "watch", "list"]    # 允许对pods资源执行get、watch和list操作，允许查看和监视Pod资源的信息

这个 Role 角色的配置表示，用户或服务账号被授予在 “default” 命名空间中执行 “get”、“watch” 和 “list” 操作以访问 Pod 资源的权限。

二、ClusterRole

1、功能

与 Role 相对，ClusterRole 则是一个集群作用域的资源。ClusterRole 同样可以用于授予 Role 能够授予的权限。 因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：

• 集群范围资源，比如节点（Node）；
• 非资源端点，比如 /healthz；
• 跨名字空间访问的名字空间作用域的资源，如 Pod。

2、案例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole                   # 定义了要创建的RBAC对象的类型，这里是一个ClusterRole对象
metadata:                           # ClusterRole对象的元信息
  # namespace: default              # 此时namespace被忽略，因为ClusterRoles不受名字空间限制。
  name: secret-reader               # 后续的配置中引用该名称来分配权限
rules:                              # ClusterRole对象对象包含的权限规则
- apiGroups: [""]                   # 空字符串""表示控制核心API组，即不属于任何自定义API组的资源。这意味着该ClusterRole控制对核心Kubernetes资源的访问
  resources: ["secrets"]            # 指定了要控制的资源类型，即 "secrets"（Secret 资源）
  verbs: ["get", "watch", "list"]   # 允许对secrets资源执行get、watch和list操作，允许查看和监视Secret资源的信息

这个 ClusterRole 配置表示，用户或服务账号被授予在整个集群范围内执行 “get”、“watch” 和 “list” 操作以访问 Secret 资源的权限。与 Role 不同，ClusterRole 可以用于控制集群范围的资源，而不仅限于特定命名空间内的资源。

三、RoleBinding

1、功能

用于将 Role 或 ClusterRole 与特定用户、服务账号或组绑定，以授予它们访问资源的权限。RoleBinding定义了谁可以执行哪些操作，并将这些规则应用到特定的命名空间或整个集群，RoleBinding 在指定的名字空间中执行授权。

因此，一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。

2、案例

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding                       # 定义了要创建的RBAC对象的类型，这里是一个RoleBinding对象
metadata:                               # RoleBinding对象的元信息
  name: read-pods                       # RoleBinding对象的名称，用来标识这个绑定
  namespace: default                    # 指定了该RoleBinding对象所属的命名空间
subjects:                               # 定义了要分配权限的主体（可指定多个主体）
- kind: User                            # 指定了主体的类型为用户
  name: jane                            # 指定了用户名为jane的用户（name字段值是区分大小写的）
  apiGroup: rbac.authorization.k8s.io   # 指定了主体所属的API组
roleRef:                                # roleRef指定与某Role或ClusterRole的绑定关系
  kind: Role                            # 此字段必须是Role或ClusterRole
  name: pod-reader                      # 此字段必须与你要绑定的Role或ClusterRole的名称匹配
  apiGroup: rbac.authorization.k8s.io   # 指定了角色所属的API组

这个 RoleBinding 配置的作用是将名为 “jane” 的用户赋予在 “default” 命名空间内执行 “pod-reader” 角色中定义的权限的权限。“pod-reader” 角色应确保已经存在（假设为 Pod 资源），并定义了对 “pods” 资源执行 “get”、“watch” 和 “list” 操作的权限。因此，“jane” 用户将能够在 “default” 命名空间中执行这些操作以查看和监视 Pod 资源的信息。

四、ClusterRoleBinding

1、功能

上面说了，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间，那你要使用 ClusterRoleBinding，它实现了跨整个集群完成访问权限的授予。

2、案例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding                # 定义了要创建的RBAC对象的类型，这里是一个ClusterRoleBinding对象
metadata:                               # ClusterRoleBinding对象的元信息
  name: read-secrets-global             # ClusterRoleBinding对象的名称，用来标识这个绑定
subjects:                               # 定义了要分配权限的主体（可指定多个主体）
- kind: Group                           # 指定了主体的类型为组
  name: manager                         # 指定了组的名称，即manager组（name字段值是区分大小写的）
  apiGroup: rbac.authorization.k8s.io   # 指定了主体所属的API组
roleRef:                                # 定义了与该绑定关联的集群角色
  kind: ClusterRole                     # 指定了与该绑定关联的角色类型，即ClusterRole
  name: secret-reader                   # 指定了要关联的集群角色的名称，即secret-reader
  apiGroup: rbac.authorization.k8s.io   # 指定了角色所属的API组

这个 ClusterRoleBinding 配置的作用是将 “manager” 组关联到名为 “secret-reader” 的集群角色上，从而赋予 “manager” 组在整个集群中执行 “secret-reader” 角色中定义的权限的权限。“secret-reader” 集群角色应确保已经存在（假设为 Secrets 资源），并定义了对 “secrets” 资源执行 “get”、“watch” 和 “list” 操作的权限，该权限在整个集群范围内生效。

特别需要注意的是：

创建了绑定之后，你不能再修改绑定对象所引用的 Role 或 ClusterRole。 试图改变绑定对象的 roleRef 将导致合法性检查错误。 如果你想要改变现有绑定对象中 roleRef 字段的内容，必须删除重新创建绑定对象。

这种限制有两个主要原因：

1. 将 roleRef 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 update 权限， 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。
2. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 roleRef， 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改了 roleRef 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。

使用 kubectl auth reconcile 命令可以创建或者更新包含 RBAC 对象的清单文件， 并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。

总结

1. Role（角色）：
   • Role 对象是 RBAC 中的一种资源，用于定义一组权限规则，以控制对指定命名空间内的资源的访问权限。
   • Role 只能授予对一个命名空间内资源的权限。
   • Role 定义了针对特定 API 组中的资源对象的操作权限。
2. ClusterRole（集群角色）：
   • ClusterRole 也是一种 RBAC 资源，但它的权限范围更广泛，可以用于定义全局集群范围内的资源权限。
   • ClusterRole 用于控制对集群级别的资源，如节点、命名空间、持久卷等的权限。
   • ClusterRole 定义了针对特定 API 组中的资源对象的操作权限。
3. RoleBinding（角色绑定）：
   • RoleBinding 是一个资源对象，用于将用户、服务账号或组与一个特定命名空间内的 Role 对象关联起来，从而赋予它们相应的权限。
   • RoleBinding 可以用于在命名空间级别定义权限。
4. ClusterRoleBinding（集群角色绑定）：
   • ClusterRoleBinding 与 RoleBinding 类似，但是它将用户、服务账号或组与 ClusterRole 关联，从而赋予他们对整个集群范围的资源的权限。
   • ClusterRoleBinding 用于在集群级别定义权限。

—END