前言
近年来，随着云原生技术的快速发展，Kubernetes 已成为云原生应用部署和管理的事实标准。而随着集群规模的扩大和业务复杂度的增加，如何对 Kubernetes 群集进行合理的权限管理变得尤为重要。Kubernetes 内建的 RBAC 权限控制机制为我们提供了一种强大灵活、社区完善、易于上手的权限管理方案，本文将详细介绍 Kubernetes 的 RBAC 机制及其实现方法，以及一些常见的实践经验。
RBAC 简介
RBAC（Role-Based Access Control）即基于角色的访问控制，是一种常用的访问控制方式，它将用户和权限之间的关系用角色进行管理，通过将不同的用户分配到不同的角色，从而实现对用户权限的控制。Kubernetes 的 RBAC 机制是基于 RBAC v1 API 来实现的，Kubernetes 集群中有两个核心的访问控制对象：Role 和 ClusterRole，以及两个核心的命名空间范围内的角色引用对象：RoleBinding 和 ClusterRoleBinding。
Role
Role 是针对单个命名空间的权限定义对象，即它只包含特定命名空间下的访问控制规则，它拥有的权限对象包括 Kubernetes 中定义的 Kinds（比如 Pods、Services、Endpoints、ConfigMaps 等）以及任何 CRD 自定义资源对象。Role 只能授予其所在的命名空间中的对应“Kinds”的权限，不包含任何跨命名空间的访问控制规则。
ClusterRole
ClusterRole 是针对整个集群的权限定义对象，它定义了跨命名空间级别的访问控制规则，可以授予用户对 Kinds 的集群范围内的权限，但不能授予额外的访问命名空间的权限。
RoleBinding
RoleBinding 是将某一 Role 授权给某个用户、组或者 ServiceAccount 的对象。它也仅限于单个命名空间内，即任何一个 RoleBinding 只能将 Role 授权给同一个命名空间内的用户、组或者 ServiceAccount。
ClusterRoleBinding
ClusterRoleBinding 是将某一 ClusterRole 授权给某个用户、组或者 ServiceAccount 的对象。与 RoleBinding 不同，ClusterRoleBinding 对象可以实现对集群多个命名空间的授权，即它授予的权限可以跨命名空间使用。
Kubernetes RBAC 实践案例
案例背景
在一个基于 Kubernetes 搭建的微服务系统中，我们需要为多个业务团队提供各自的访问权限，以确保系统的稳定运行和安全性。在此背景下，我们将使用 RBAC 机制来实现不同用户、组和 ServiceAccount 的访问权限管理。
案例实现
我们将按照以下步骤实现 RBAC 权限管理：
1、创建 Namespace 和 ServiceAccount
首先，我们需要创建一个 Namespace，以便为这个 Namespace 内的资源授权。
----- --------- ----------- -- --------- ----- -------
同时，我们也需要创建一个 ServiceAccount，以便后续将授权绑定到这个 ServiceAccount 上。
----------- -- ----- -------------- --------- ----- ------- ---------- -------
当 ServiceAccount 被创建后，Kubernetes 自动为它创建了一个名为 test-sa-token-xxxx 的 secret 对象，其中 xxxx 部分是一个随机码，这个 secret 用于存储访问令牌用于授权。
2、创建 ClusterRole 和 ClusterRoleBinding
现在我们需要创建一个 ClusterRole 来定义集群范围内的访问控制权限规则：
----- ----------- ----------- ---------------------------- --------- ----- ------- ------ - ---------- ---- - -- -- ---- --- - ---------- - ---- ------ - --- - ----- - ----
在上面的示例中，我们创建了一个 ClusterRole，名为 test-cr，它的规则是：允许所有用户（不属于任何角色）在集群范围内对 Pods 进行 get、watch 和 list 操作。
接下来，我们需要将这个 ClusterRole 授权给 ServiceAccount，创建一个 ClusterRoleBinding，如下所示：
----- ------------------ ----------- ---------------------------- --------- ----- -------- --------- - ----- -------------- ----- ------- ---------- ------- -------- ----- ----------- ----- ------- --------- -------------------------
在上面的示例中，我们创建了一个 ClusterRoleBinding，名为 test-crb，它将 test-cr 授权给 test-sa 这个 ServiceAccount。在这个 ServiceAccount 授权范围内，任何使用该 ServiceAccount 的 Pod 均有获取、观察和列出 Pod 对象的权限。
3、创建 Role 和 RoleBinding
在 Namespace 内，我们需要创建一个 Role 来定义 Namespace 范围内的访问控制权限规则：
----- ---- ----------- ---------------------------- --------- ----- --------- ---------- ------- ------ - ---------- ---- - -- -- ---- --- - ---------- - ---------- ------ - --- - ----- - ----
在上面的示例中，我们创建了一个 Role，名为 test-role，它的规则是：允许所有用户（不属于任何角色）在 Namespace test-ns 范围内对 ConfigMaps 进行 get、watch 和 list 操作。
接下来，我们需要将这个 Role 授权给 ServiceAccount，创建一个 RoleBinding，如下所示：
----- ----------- ----------- ---------------------------- --------- ----- ----------------- ---------- ------- --------- - ----- -------------- ----- ------- ---------- ------- -------- ----- ---- ----- --------- --------- -------------------------
在上面的示例中，我们创建了一个 RoleBinding，名为 test-role-binding，它授权 test-role 给 ServiceAccount test-sa 在命名空间 test-ns 范围内有效。
在以上步骤完成后，我们就实现了权限管理。现在我们可以创建一个使用 test-sa ServiceAccount 的 Pod，来测试权限是否生效：
----------- --
----- ---
---------
----- --------
---------- -------
-----
------------------- -------
-----------
- ----- --------------
------ -----
------
- -------------- --根据上面的定义，这个 Pod 将使用 test-sa ServiceAccount。
现在，我们可以登录到 Pod，查看 ConfigMaps，如下所示：
- ------- ---- --- -------- -- ------- -- - ---- ------------ - ------- ------ -- ------- ------- -- ---- - ---- ----------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------
我们可以通过以上命令查看到 ConfigMap 列表，证明已经成功实现权限管理。
结论
在本文中，我们详细介绍了 Kubernetes 的 RBAC 实现机制和权限管理的实践案例。合理的权限控制可以确保 Kubernetes 集群的稳定性和安全性，RBAC 机制为我们提供了一个良好的解决方案。在实践过程中，我们可以根据需求，选择不同的授权对象和权限申请方式来达到预期的目标。
来源：JavaScript中文网 ，转载请联系管理员！ 本文地址：https://www.javascriptcn.com/post/66f8015dc5c563ced5b80f96