🐇明明跟你说过：个人主页
🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅
🔖行路有良友，便是天堂🔖
目录
一、前言
1、k8s简介
2、RBAC简介
二、RBAC核心概念
1、角色（Role）与集群角色（ClusterRole）
2、角色绑定（RoleBinding）与集群角色绑定（ClusterRoleBinding）
3、主体（Subject）
三、RBAC在Kubernetes中的实现
1、Kubernetes API Server与RBAC组件
2、YAML配置RBAC策略
3、RBAC权限检查流程
四、RBAC实践应用
1、Pod管理权限
2、Namespace隔离权限
3、权限最小化原则
一、前言
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 中实现权限最小化原则，提高系统的安全性和可靠性。
💕💕💕每一次的分享都是一次成长的旅程，感谢您的陪伴和关注。希望这些关于Kubernetes的文章能陪伴您走过技术的一段旅程，共同见证成长和进步！😺😺😺文章来源：https://www.toymoban.com/news/detail-860792.html
🧨🧨🧨让我们一起在技术的海洋中探索前行，共同书写美好的未来！！！文章来源地址https://www.toymoban.com/news/detail-860792.html
到了这里，关于K8s RBAC认证授权深度解析的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
