rbac权限管理实现



基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。

RBAC 鉴权机制使用 来驱动鉴权决定， 允许你通过 Kubernetes API 动态配置策略。

要启用 RBAC，在启动 时将 参数设置为一个逗号分隔的列表并确保其中包含 。

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。你可以像使用其他 Kubernetes 对象一样， 通过类似 这类工具描述或修补 RBAC 。

RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。 这些权限是纯粹累加的（不存在拒绝某操作的规则）。

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

与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole） 是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。

ClusterRole 有若干用法。你可以用它来：

1. 定义对某名字空间域对象的访问权限，并将在个别名字空间内被授予访问权限；
2. 为名字空间作用域的对象设置访问权限，并被授予跨所有名字空间的访问权限；
3. 为集群作用域的资源定义访问权限。

如果你希望在名字空间内定义角色，应该使用 Role； 如果你希望定义集群范围的角色，应该使用 ClusterRole。

Role 示例

下面是一个位于 "default" 名字空间的 Role 的示例，可用来授予对 的读访问权限：

ClusterRole 同样可以用于授予 Role 能够授予的权限。 因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：

• 集群范围资源（比如）
• 非资源端点（比如 ）
• 跨名字空间访问的名字空间作用域的资源（如 Pod）

  比如，你可以使用 ClusterRole 来允许某特定用户执行

下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 授予读访问权限， 或者跨名字空间的访问权限（取决于该角色是如何绑定的）：

Role 或 ClusterRole 对象的名称必须是合法的路径分段名称。

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 它包含若干主体（Subject）（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。

一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。

RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的 路径分段名称。

RoleBinding 示例

下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 这样，用户 "jane" 就具有了读取 "default" 名字空间中所有 Pod 的权限。

RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， 之后在多个名字空间中复用。

例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，"dave"（这里的主体， 区分大小写）只能访问 "development" 名字空间中的 Secret 对象，因为 RoleBinding 所在的名字空间（由其 metadata 决定）是 "development"。

ClusterRoleBinding 示例

要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。 下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 Secret。

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

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

1. 将 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 权限， 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。

2. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 ， 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改了 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。

命令 可以创建或者更新包含 RBAC 对象的清单文件， 并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。 更多相关信息请参照命令用法和示例。

在 Kubernetes API 中，大多数资源都是使用对象名称的字符串表示来呈现与访问的。 例如，对于 Pod 应使用 "pods"。 RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 有一些 Kubernetes API 涉及子资源（subresource），例如 Pod 的日志。 对 Pod 日志的请求看起来像这样：

在这里， 对应名字空间作用域的 Pod 资源，而 是 的子资源。 在 RBAC 角色表达子资源时，使用斜线（）来分隔资源和子资源。 要允许某主体读取 同时访问这些 Pod 的 子资源，你可以这样写：

对于某些请求，也可以通过 列表按名称引用资源。 在指定时，可以将请求限定为资源的单个实例。 下面的例子中限制可以 和 一个名为 的 ：

你可以使用通配符 批量引用所有的 、 和 对象，无需逐一引用。 对于 ，你可以将通配符 作为后缀实现全局通配， 对于 ，空集表示没有任何限制。 下面的示例对 API 组中所有当前和未来资源执行所有动作。 这类似于内置的 。

你可以将若干 ClusterRole 聚合（Aggregate） 起来，形成一个复合的 ClusterRole。 作为集群控制面的一部分，控制器会监视带有 的 ClusterRole 对象集合。 为控制器定义一个标签供后者匹配应该组合到当前 ClusterRole 的 字段中的 ClusterRole 对象。

下面是一个聚合 ClusterRole 的示例：

如果你创建一个与某个已存在的聚合 ClusterRole 的标签选择算符匹配的 ClusterRole， 这一变化会触发新的规则被添加到聚合 ClusterRole 的操作。 下面的例子中，通过创建一个标签同样为 的 ClusterRole，新的规则可被添加到 "monitoring" ClusterRole 中。

默认的面向用户的角色使用 ClusterRole 聚合。 这使得作为集群管理员的你可以为扩展默认规则，包括为定制资源设置规则， 比如通过 CustomResourceDefinitions 或聚合 API 服务器提供的定制资源。

例如，下面的 ClusterRoles 让默认角色 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， "view" 角色对 CronTab 资源拥有读操作权限。 你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 。

Role 示例

以下示例均为从 Role 或 ClusterRole 对象中截取出来，我们仅展示其 部分。

允许读取在核心 下的 ：

允许在 API 组中读/写 Deployment（在 HTTP 层面，对应 URL 中资源部分为 ）：

允许读取核心 API 组中的 Pod 和读/写 API 组中的 Job 资源：

允许读取名称为 "my-config" 的 ConfigMap（需要通过 RoleBinding 绑定以限制为某名字空间中特定的 ConfigMap）：

允许读取在核心组中的 资源（因为 是集群作用域的，所以需要 ClusterRole 绑定到 ClusterRoleBinding 才生效）：

允许针对非资源端点 和其子路径上发起 GET 和 POST 请求 （必须在 ClusterRole 绑定 ClusterRoleBinding 才生效）：

RoleBinding 或者 ClusterRoleBinding 可绑定角色到某主体（Subject） 上。 主体可以是组，用户或者。

Kubernetes 用字符串来表示用户名。 用户名可以是普通的用户名，像 "alice"；或者是邮件风格的名称，如 ""， 或者是以字符串形式表达的数字 ID。你作为 Kubernetes 管理员负责配置身份认证模块， 以便后者能够生成你所期望的格式的用户名。

在 Kubernetes 中，身份认证（Authenticator）模块提供用户组信息。 与用户名一样，用户组名也用字符串来表示，而且对该字符串没有格式要求， 只是不能使用保留的前缀 。

服务账户（ServiceAccount） 的用户名前缀为 ，属于前缀为 的用户组。

RoleBinding 示例

下面示例是 中的片段，仅展示其 的部分。

对于名称为 的用户：

对于名称为 的用户组：

对于 名字空间中的默认服务账户：

对于 "qa" 名称空间中的所有服务账户：

对于在任何名字空间中的服务账户：

对于所有已经过身份认证的用户：

对于所有未通过身份认证的用户：

对于所有用户：

API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 这其中许多是以 为前缀的，用以标识对应资源是直接由集群控制面管理的。 所有的默认 ClusterRole 和 ClusterRoleBinding 都有 标签。

在每次启动时，API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限， 并更新默认的 ClusterRoleBinding 以增加缺失的各类主体。 这种自动协商机制允许集群去修复一些不小心发生的修改， 并且有助于保证角色和角色绑定在新的发行版本中有权限或主体变更时仍然保持最新。

如果要禁止此功能，请将默认 ClusterRole 以及默认 ClusterRoleBinding 的 注解设置成 。 注意，缺少默认权限和角色绑定主体可能会导致集群无法正常工作。

如果基于 RBAC 的鉴权机制被启用，则自动协商功能默认是被启用的。

无论是经过身份验证的还是未经过身份验证的用户， 默认的集群角色绑定都授权他们读取被认为是可安全地公开访问的 API（包括 CustomResourceDefinitions）。 如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中添加 的配置选项。

通过运行命令 可以查看这些角色的配置信息:

一些默认的 ClusterRole 不是以前缀 开头的。这些是面向用户的角色。 它们包括超级用户（Super-User）角色（）、 使用 ClusterRoleBinding 在集群范围内完成授权的角色（）、 以及使用 RoleBinding 在特定名字空间中授予的角色（、、）。

面向用户的 ClusterRole 使用 ClusterRole 聚合以允许管理员在这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 、 或者 ， 可以创建带有以下一个或多个标签的 ClusterRole：

Kubernetes 运行内建于 Kubernetes 控制面的。 当使用 参数启动时，kube-controller-manager 使用单独的服务账户来启动每个控制器。 每个内置控制器都有相应的、前缀为 的角色。 如果控制管理器启动时未设置 ， 它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。 这些角色包括：

RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。 由于这一点是在 API 级别实现的，所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。

只有在符合下列条件之一的情况下，你才能创建/更新角色:

1. 你已经拥有角色中包含的所有权限，且其作用域与正被修改的对象作用域相同。 （对 ClusterRole 而言意味着集群范围，对 Role 而言意味着相同名字空间或者集群范围）。
2. 你被显式授权在 API 组中的 或 资源使用 动词。

例如，如果 没有列举集群范围所有 Secret 的权限，他将不能创建包含该权限的 ClusterRole。 若要允许用户创建/更新角色：

1. 根据需要赋予他们一个角色，允许他们根据需要创建/更新 Role 或者 ClusterRole 对象。
2. 授予他们在所创建/更新角色中包含特殊权限的权限:
   • 隐式地为他们授权（如果它们试图创建或者更改 Role 或 ClusterRole 的权限， 但自身没有被授予相应权限，API 请求将被禁止）。
   • 通过允许他们在 Role 或 ClusterRole 资源上执行 动作显式完成授权。 这里的 和 资源包含在 API 组中。

只有你已经具有了所引用的角色中包含的全部权限时，或者你被授权在所引用的角色上执行 动词时，你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。 例如，如果用户 没有列举集群范围所有 Secret 的能力，则他不可以创建 ClusterRoleBinding 引用授予该许可权限的角色。 如要允许用户创建或更新角色绑定：

1. 赋予他们一个角色，使得他们能够根据需要创建或更新 RoleBinding 或 ClusterRoleBinding 对象。
2. 授予他们绑定某特定角色所需要的许可权限：
   • 隐式授权下，可以将角色中包含的许可权限授予他们；
   • 显式授权下，可以授权他们在特定 Role （或 ClusterRole）上执行 动词的权限。

例如，下面的 ClusterRole 和 RoleBinding 将允许用户 把名字空间 中的 、 和 角色赋予其他用户：

当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要：

• 使用用户组为 的凭据，该用户组由默认绑定关联到 这个超级用户角色。

创建 Role 对象，定义在某一名字空间中的权限。例如:

• 创建名称为 “pod-reader” 的 Role 对象，允许用户对 Pods 执行 、 和 操作：

• 创建名称为 “pod-reader” 的 Role 对象并指定 ：

• 创建名为 “foo” 的 Role 对象并指定 ：

• 创建名为 “foo” 的 Role 对象并指定子资源权限:

• 创建名为 “my-component-lease-holder” 的 Role 对象，使其具有对特定名称的资源执行 get/update 的权限：

创建 ClusterRole 对象。例如：

• 创建名称为 “pod-reader” 的 ClusterRole 对象，允许用户对 Pods 对象执行 、 和 操作：

• 创建名为 “pod-reader” 的 ClusterRole 对象并指定 ：

• 创建名为 “foo” 的 ClusterRole 对象并指定 ：

• 创建名为 “foo” 的 ClusterRole 对象并指定子资源:

• 创建名为 “foo” 的 ClusterRole 对象并指定 ：

• 创建名为 “monitoring” 的 ClusterRole 对象并指定 ：

在特定的名字空间中对 或 授权。例如：

• 在名字空间 “acme” 中，将名为 的 ClusterRole 中的权限授予名称 “bob” 的用户:

• 在名字空间 “acme” 中，将名为 的 ClusterRole 中的权限授予名字空间 “acme” 中名为 的服务账户：

• 在名字空间 “acme” 中，将名为 的 ClusterRole 对象中的权限授予名字空间 “myappnamespace” 中名称为 的服务账户：

在整个集群（所有名字空间）中用 ClusterRole 授权。例如：

• 在整个集群范围，将名为 的 ClusterRole 中定义的权限授予名为 “root” 用户：

• 在整个集群范围内，将名为 的 ClusterRole 的权限授予名为 “system:kube-proxy” 的用户：

• 在整个集群范围内，将名为 的 ClusterRole 中定义的权限授予 “acme” 名字空间中名为 “myapp” 的服务账户：

使用清单文件来创建或者更新 API 对象。

尚不存在的对象会被创建，如果对应的名字空间也不存在，必要的话也会被创建。 已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 ，可以删除额外的权限。

已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 ，则可以删除多余的主体。

例如:

• 测试应用 RBAC 对象的清单文件，显示将要进行的更改：

• 应用 RBAC 对象的清单文件，保留角色（）中的额外权限和绑定（）中的其他主体：

• 应用 RBAC 对象的清单文件，删除角色（）中的额外权限和绑定中的其他主体：

默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 但是不会对 名字空间之外的服务账户授予权限。 （除了 API 发现角色 授予的权限）

这使得你可以根据需要向特定 ServiceAccount 授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 粗粒度的授权可能导致 ServiceAccount 被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， 但更易于管理。

按从最安全到最不安全的顺序，存在以下方法：

1. 为特定应用的服务账户授予角色（最佳实践）

   这要求应用在其 Pod 规约中指定 ， 并额外创建服务账户（包括通过 API、应用程序清单、 等）。

   例如，在名字空间 “my-namespace” 中授予服务账户 “my-sa” 只读权限：

2. 将角色授予某名字空间中的 “default” 服务账户

   如果某应用没有指定 ，那么它将使用 “default” 服务账户。

   例如，在名字空间 "my-namespace" 中授予服务账户 "default" 只读权限：

   许多插件组件在 名字空间以 “default” 服务账户运行。 要允许这些插件组件以超级用户权限运行，需要将集群的 权限授予 名字空间中的 “default” 服务账户。

3. 将角色授予名字空间中所有服务账户

   如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账户， 可以将角色授予该名字空间的服务账户组。

   例如，在名字空间 “my-namespace” 中的只读权限授予该名字空间中的所有服务账户：

4. 在集群范围内为所有服务账户授予一个受限角色（不鼓励）

   如果你不想管理每一个名字空间的权限，你可以向所有的服务账户授予集群范围的角色。

   例如，为集群范围的所有服务账户授予跨所有名字空间的只读权限：

5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励）

   如果你不在乎如何区分权限，你可以将超级用户访问权限授予所有服务账户。

在 Kubernetes v1.22 之前版本创建的集群里， “edit” 和 “admin” 聚合角色包含对 EndpointSlices（和 Endpoints）的写权限。 作为 CVE-2021-25740 的缓解措施， 此访问权限不包含在 Kubernetes 1.22 以及更高版本集群的聚合角色里。

升级到 Kubernetes v1.22 版本的现有集群不会包括此变化。 CVE 公告包含了在现有集群里限制此访问权限的指引。

如果你希望在新集群的聚合角色里保留此访问权限，你可以创建下面的 ClusterRole：

原来运行较老版本 Kubernetes 的集群通常会使用限制宽松的 ABAC 策略， 包括授予所有服务帐户全权访问 API 的能力。

默认的 RBAC 策略为控制面组件、节点和控制器等授予有限的权限，但不会为 名字空间外的服务账户授权（除了 API 发现角色授予的权限）。

这样做虽然安全得多，但可能会干扰期望自动获得 API 权限的现有工作负载。 这里有两种方法来完成这种转换:

同时运行 RBAC 和 ABAC 鉴权模式， 并指定包含现有的 ABAC 策略的策略文件：

关于命令行中的第一个选项：如果早期的鉴权组件，例如 Node，拒绝了某个请求，则 RBAC 鉴权组件尝试对该 API 请求鉴权。如果 RBAC 也拒绝了该 API 请求，则运行 ABAC 鉴权组件。这意味着被 RBAC 或 ABAC 策略所允许的任何请求都是被允许的请求。

如果 kube-apiserver 启动时，RBAC 组件的日志级别为 5 或更高（ 或 ）， 你可以在 API 服务器的日志中看到 RBAC 拒绝的细节（前缀 ） 你可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。

一旦你将角色授予服务账户且工作负载运行时， 服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。

你可以使用 RBAC 角色绑定复制宽松的 ABAC 策略。

在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的信息安全需求。

版权声明：

本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。

本文网址：https://www.mushiming.com/mjsbk/10399.html