K8s RBAC认证授权深度解析

随着Kubernetes在云原生领域的广泛应用，如何有效地管理和控制用户对集群资源的访问权限成为了一个重要的问题。基于角色的访问控制（RBAC）作为一种灵活的权限管理机制，在Kubernetes中发挥着至关重要的作用。本文深入探讨了Kubernetes RBAC认证授权的核心概念、实现方式以及实践应用，旨在帮助读者更好地理解和管理Kubernetes集群中的权限问题。

weixin_53269650

1846人浏览 · 2024-04-20 07:30:00

weixin_53269650 · 2024-04-20 07:30:00 发布

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

1、角色（Role）与集群角色（ClusterRole）

2、角色绑定（RoleBinding）与集群角色绑定（ClusterRoleBinding）

3、主体（Subject）

三、RBAC在Kubernetes中的实现

1、Kubernetes API Server与RBAC组件

一、前言

1、k8s简介

Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。

Kubernetes（简称K8s）的前世今生可以追溯到谷歌（Google）内部的一个项目，它起源于2003年，当时谷歌正面临着不断增长的应用程序和服务的管理挑战。这个项目最初被称为"Borg"，是一个早期的容器编排系统。Borg 的成功经验成为 Kubernetes 开发的契机。

有关k8s起源的介绍，请参考《初识K8s之前世今生、架构、组件、前景》这篇文章

Kubernetes的优点包括可移植性、可伸缩性和扩展性。它使用轻型的YAML清单文件实现声明性部署方法，对于应用程序更新，无需重新构建基础结构。管理员可以计划和部署容器，根据需要扩展容器并管理其生命周期。借助Kubernetes的开放源代码API，用户可以通过首选编程语言、操作系统、库和消息传递总线来构建应用程序，还可以将现有持续集成和持续交付（CI/CD）工具集成。

2、RBAC简介

K8s RBAC（Role-Based Access Control，基于角色的访问控制）是Kubernetes（通常简称为K8s）中用于控制用户对集群资源访问权限的一种机制。RBAC允许管理员通过定义角色（Role）和角色绑定（RoleBinding）来管理用户对集群资源的访问权限。

二、RBAC核心概念

1、角色（Role）与集群角色（ClusterRole）

在 Kubernetes 中，RBAC（Role-Based Access Control）的核心概念包括角色（Role）和集群角色（ClusterRole），它们用于定义对资源的访问权限。

下面是它们的基本介绍：

角色（Role）：

Role 是一种 Kubernetes 对象，它定义了对特定命名空间内资源的一组权限。这些权限可以是创建、读取、更新和删除等操作，针对特定的 API 资源对象（如 Pod、Service、ConfigMap 等）。
Role 对象只在特定命名空间内生效，即它所定义的权限只适用于该命名空间内的资源。

集群角色（ClusterRole）：

ClusterRole 也是一种 Kubernetes 对象，它与 Role 类似，但是作用范围更广泛，可以应用于整个集群，而不限于特定的命名空间。
ClusterRole 定义了对集群范围内资源的权限，可以包括所有命名空间中的资源，也可以包括集群级别的资源，例如节点、命名空间等。

总的来说，角色（Role）和集群角色（ClusterRole）的作用是相似的，都用于定义对 Kubernetes 资源的访问权限。它们的区别主要在于作用范围：Role 仅作用于特定命名空间内的资源，而 ClusterRole 则作用于整个集群的资源。

2、角色绑定（RoleBinding）与集群角色绑定（ClusterRoleBinding）

在 Kubernetes 中，角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）用于将用户、组或服务账户与角色或集群角色关联起来，从而赋予它们相应的权限。它们的作用是将权限分配给特定的实体，使其能够执行定义在角色或集群角色中的操作。

以下是它们的基本介绍：

角色绑定（RoleBinding）：

RoleBinding 是一种 Kubernetes 对象，用于将特定的角色（Role）与特定的用户、组或服务账户绑定在一起，从而赋予它们在某个命名空间内的资源上执行操作的权限。
例如，可以创建一个 RoleBinding，将角色 "编辑者"（Editor）与用户 "Alice" 绑定在一起，这样 Alice 就具有在特定命名空间内编辑资源的权限。

集群角色绑定（ClusterRoleBinding）：

ClusterRoleBinding 类似于 RoleBinding，但是作用范围更广泛，它用于将集群角色（ClusterRole）与用户、组或服务账户绑定在一起，赋予它们在整个集群范围内执行操作的权限。
例如，可以创建一个 ClusterRoleBinding，将集群角色 "集群管理员"（ClusterAdmin）与用户组 "管理员组" 绑定在一起，这样管理员组的成员就具有在整个集群中执行管理员操作的权限。

通过角色绑定和集群角色绑定，Kubernetes 管理员可以灵活地控制不同用户、组或服务账户对集群资源的访问权限，从而实现安全的权限管理。

3、主体（Subject）

在 Kubernetes 中，主体（Subject）是指具有身份的实体，通常是用户、组或服务账户。主体通过角色绑定（RoleBinding）或集群角色绑定（ClusterRoleBinding）与角色或集群角色关联在一起，从而获取对 Kubernetes 资源的访问权限。

主体可以是以下几种类型之一：

用户：Kubernetes 可以与外部身份验证服务集成，以允许使用基于用户名和密码的身份验证机制登录到集群中。登录成功后，用户将被视为主体，并根据其被分配的角色获得相应的权限。
组：在某些情况下，将一组用户组织在一起，并为整个组分配权限可能更为方便。在 Kubernetes 中，可以通过角色绑定或集群角色绑定将组与角色或集群角色关联起来，从而将权限分配给组内的所有成员。
服务账户：服务账户是 Kubernetes 中的一种特殊类型的身份，用于表示正在运行的容器或 Pod。它们通常用于实现应用程序和其他 Kubernetes 部署的自动化任务。通过为服务账户分配适当的角色或集群角色，可以确保它们具有执行所需操作所需的权限。

总之，主体在 Kubernetes 中代表了具有身份的实体，通过角色绑定或集群角色绑定与角色或集群角色相关联，从而获得对 Kubernetes 资源的访问权限。

三、RBAC在Kubernetes中的实现

1、Kubernetes API Server与RBAC组件

Kubernetes API Server 与 RBAC 组件之间实现认证授权机制的过程如下：

认证（Authentication）：

当用户或服务向 Kubernetes API Server 发起请求时，首先会经过认证阶段。认证过程验证请求的身份是否合法，并确定请求的发起者是谁。
Kubernetes 支持多种认证方式，包括基本认证、客户端证书认证、Token 认证、OpenID Connect（OIDC）认证等。用户可以根据实际需求选择适合的认证方式。
认证成功后，API Server 将为请求分配一个身份标识，用于后续的授权操作。

授权（Authorization）：

在认证成功后，API Server 将请求与 RBAC 规则进行匹配，以确定请求是否被允许执行。这个过程称为授权。
RBAC 规则由 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 定义，用于描述用户、组或服务账户在集群中的访问权限。
当请求到达 API Server 后，API Server 将根据请求中包含的身份信息，以及 RBAC 规则中定义的权限，来决定是否允许执行请求所涉及的操作。
如果请求的身份与 RBAC 规则匹配且具有足够的权限，则 API Server 授权请求执行操作；否则，请求将被拒绝，并返回相应的错误信息。

综上所述，Kubernetes API Server 与 RBAC 组件之间实现认证授权机制的过程包括认证和授权两个阶段。认证阶段用于验证请求的身份，确定请求的发起者是谁；授权阶段则用于根据 RBAC 规则检查请求的权限，决定是否允许执行操作。这两个阶段共同构成了 Kubernetes 集群中的访问控制机制，确保请求的合法性和安全性。

2、YAML配置RBAC策略

以下是一个示例 YAML 文件，用于配置 Kubernetes 中的 RBAC 策略：

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

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

上述 YAML 文件定义了一个名为 pod-reader 的 Role，该 Role 具有对 pods 资源的 get 和 list 权限。然后通过 RoleBinding 将该 Role 绑定到名为 alice 的用户上，使其具有读取 Pod 的权限。

解释一下：

Role 定义了一组权限规则，指定了对哪些资源的哪些操作是允许的。
RoleBinding 将一个或多个 Role 绑定到一个或多个用户、组或服务账户上，从而赋予它们相应的权限。

在实际使用时，可以根据需求修改 Role 中的权限规则，并通过 RoleBinding 将其绑定到指定的用户、组或服务账户上，以实现 RBAC 的策略配置。

3、RBAC权限检查流程

RBAC（基于角色的访问控制）在 Kubernetes 中的权限检查流程如下：

1. 认证（Authentication）：用户或服务通过身份验证机制（如证书、令牌等）与 Kubernetes API Server 建立连接。
2. 授权（Authorization）：一旦用户或服务通过认证，Kubernetes API Server 将对请求进行授权检查。授权检查的过程包括以下步骤：

识别主体（Identifying the Subject）：API Server 根据认证信息识别请求的主体，即发起请求的用户、服务或实体。
确定请求的操作和目标资源：API Server 解析请求中包含的操作（例如 GET、POST、DELETE 等）和目标资源（如 Pod、Deployment 等）。
查询 RBAC 规则：API Server 根据主体和请求的操作/资源，查询与之相关的 RBAC 规则。这些规则通常存储在集群中的 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 中。
匹配规则：API Server 将查询到的规则与请求进行匹配。如果存在与请求匹配的规则，则请求被授权执行。否则，请求将被拒绝。

3. 执行请求（Executing the Request）：如果请求通过了授权检查，API Server 将执行请求所代表的操作，例如创建、更新或删除资源。

通过以上流程，Kubernetes 的 RBAC 系统实现了对用户和服务的细粒度访问控制，确保只有经过授权的用户和服务才能执行特定的操作。

四、RBAC实践应用

1、Pod管理权限

在 Kubernetes 中，通过 RBAC 可以实现对 Pod 管理的权限控制。以下是一些常见的 Pod 管理权限管理场景：

只读权限：某些用户或服务可能只需要查看集群中的 Pod 信息，而不具备修改或删除 Pod 的权限。可以通过创建只读角色（如只包含 Pod 的 GET 操作）并绑定给相应的用户或服务来实现。
创建 Pod 权限：某些用户或服务需要能够创建 Pod，但不具备删除或修改 Pod 的权限。可以通过创建包含 Pod 的创建权限（如 POST 操作）的角色并绑定给相应的用户或服务来实现。
管理所有 Pod 权限：特定管理员用户可能需要对集群中的所有 Pod 进行管理，包括创建、更新和删除。可以通过创建包含所有 Pod 操作权限的角色并将其绑定给这些管理员用户来实现。
命名空间级别的权限：在命名空间级别进行 Pod 管理权限的划分。可以为每个命名空间创建不同的角色，然后将相应的用户或服务绑定到这些角色上，以限制他们在特定命名空间中的 Pod 管理权限。
集群级别的权限：对于需要在整个集群范围内进行 Pod 管理的操作，可以使用集群角色（ClusterRole）和集群角色绑定（ClusterRoleBinding）来实现。这允许用户或服务在整个集群中执行 Pod 管理操作，而不受命名空间的限制。

下面是一个YAML示例。授权用户test对默认名称空间下的nginx这个pod，只有查看的权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: view-nginx-pod
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-view-nginx-pod
  namespace: default
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: view-nginx-pod
  apiGroup: rbac.authorization.k8s.io

在这个示例中：

创建了一个名为 view-nginx-pod 的角色（Role），它授予了对默认命名空间下的 Pod 的 get, list 和 watch 权限。
创建了一个名为 test-view-nginx-pod 的角色绑定（RoleBinding），将用户 test 绑定到了刚刚创建的角色上，从而赋予了用户 test 查看默认命名空间下的 Pod 的权限。

2、Namespace隔离权限

在 Kubernetes 中，通过 RBAC 可以很容易地实现 Namespace 的隔离权限。

下面是一个授予用户 test 对命名空间 example 的完全权限的 YAML 示例：

apiVersion: v1
kind: Namespace
metadata:
  name: example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: admin-role
  namespace: example
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-admin-binding
  namespace: example
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: admin-role
  apiGroup: rbac.authorization.k8s.io

这个示例做了以下事情：

创建了一个名为 example 的命名空间。
创建了一个名为 admin-role 的角色（Role），授予了对命名空间 example 中所有资源的所有操作权限。
创建了一个名为 test-admin-binding 的角色绑定（RoleBinding），将用户 test 绑定到了刚刚创建的 admin-role 角色上，从而赋予了用户 test 对命名空间 example 的完全权限。

通过这种方式，可以将不同的用户或服务隔离到不同的命名空间，并为他们分配适当的权限，以实现更好的权限管理和资源隔离。

3、权限最小化原则

权限最小化原则是指在设计权限时，应该按照最小权限原则，即为用户或实体分配尽可能少的权限，以限制其访问范围和操作权限，从而降低潜在的安全风险和错误操作的影响范围。

在 Kubernetes 中，实现权限最小化的方式包括：

使用 RBAC 进行细粒度授权： RBAC（Role-Based Access Control）允许管理员为不同的用户、服务账号或组分配不同的权限，可以根据需要创建自定义的角色（Role）和角色绑定（RoleBinding），并将其绑定到命名空间或集群资源上，从而实现对资源的精细化控制。
限制 Pod 的权限：在 Kubernetes 中，可以通过 Pod Security Policies（PSP）或其他安全策略来限制 Pod 的权限，例如限制 Pod 的权限，限制 Pod 对主机的访问等，从而降低容器被攻击或滥用的风险。
使用 Network Policies 进行网络访问控制： Network Policies 允许管理员定义网络访问策略，控制 Pod 之间的网络通信和对外部网络的访问，可以限制不同命名空间或 Pod 的通信，实现网络访问的最小化。
使用 Pod Security Context 进行权限控制： Pod Security Context 允许管理员在创建 Pod 时指定一些安全上下文参数，例如运行用户、运行组、权限掩码等，可以限制容器的操作权限，减少潜在的安全风险。

通过以上方法，可以在 Kubernetes 中实现权限最小化原则，提高系统的安全性和可靠性。