Kubernetes 访问控制 - RBAC 鉴权

Kubernetes 访问控制 - RBAC 鉴权_第1张图片

Author:rab


目录

    • 前言
    • 一、Role
    • 二、ClusterRole
    • 三、RoleBinding
    • 四、ClusterRoleBinding
    • 总结


前言

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、功能

用于将 RoleClusterRole 与特定用户、服务账号或组绑定,以授予它们访问资源的权限。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(集群角色绑定)
    • ClusterRoleBindingRoleBinding 类似,但是它将用户、服务账号或组与 ClusterRole 关联,从而赋予他们对整个集群范围的资源的权限。
    • ClusterRoleBinding 用于在集群级别定义权限。

—END

你可能感兴趣的:(云原生,kubernetes,云原生)