【kubernetes】安全机制

一.安全机制

安全机制说明

Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介， 也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。 在 Kubernetes (k8s) 中，认证、鉴权和准入控制构成了确保集群安全的三大核心机制，它们分别在不同的阶段执行，以确保只有经过验证的请求才能对资源执行允许的操作。它们的关系如下：

1. 认证 (Authentication)

• 作用：认证是用来确认请求的身份，即识别发起请求的用户或服务。
• 认证方式
  • X.509 证书：Kubernetes 常用的认证方式之一是通过客户端提供的证书进行认证，证书由集群管理员签发。
  • Bearer Tokens（持有者令牌）：常见于使用 kubectl 连接 API Server 的场景。
  • 外部认证系统：Kubernetes 支持通过集成 OIDC、LDAP 等外部系统进行认证。
• 过程：当用户发送请求时，Kubernetes API Server 会通过这些认证方法验证请求者的身份，确保它是可信用户。

2. 鉴权 (Authorization)

• 作用：在通过认证后，鉴权用于决定经过认证的用户是否有权对某个资源执行请求的操作（如创建、删除、更新等）。
• 授权方式
  • RBAC (Role-Based Access Control)：Kubernetes 主要使用基于角色的访问控制机制。管理员通过定义 Role 或 ClusterRole 来指定权限，然后将这些角色绑定到用户或组上，控制他们对资源的访问。
  • ABAC (Attribute-Based Access Control)：Kubernetes 也支持通过自定义的策略文件来基于属性控制访问。
  • Webhook Authorization：允许通过调用外部服务来决定是否允许某个请求。
• 过程：认证通过后，API Server 会检查用户是否有足够权限执行请求，通过 RoleBinding 和 ClusterRoleBinding 来确定是否允许该请求继续。

3. 准入控制 (Admission Control)

• 作用：准入控制是在认证和授权后进一步对请求进行检查和修改，决定是否允许请求继续。准入控制可以动态修改请求或拒绝不合规的请求。

• 准入控制器

  • Mutating Admission Controllers（可变准入控制器）：

    • 职责：它们的作用是在对象被创建或更新时，允许修改该对象的配置。常见的 Mutating Admission Controllers 包括 PodPreset、DefaultTolerationSeconds，它们可以在请求被接受之前自动填充一些默认值或对配置进行修改。

      作用流程：在对象创建时，先经过 Mutating Admission Controllers 进行修改操作，比如为 Pod 自动添加某些标签、容忍度等配置。

  • Validating Admission Controllers（验证准入控制器）：

    • 职责：这些控制器的主要作用是在资源创建或更新前进行验证，确保其符合集群的安全和策略要求。如果资源不符合要求，则请求会被拒绝。例如，PodSecurity 就是一个 Validating Admission Controller，它可以验证 Pod 是否符合特定的安全策略。

      作用流程：在 Mutating Admission Controllers 之后，Validating Admission Controllers 会检查请求是否符合策略要求。如果不符合，则拒绝该操作。

• 常见的准入控制器

  • ResourceQuota：检查命名空间是否超过资源配额。
  • PodSecurityPolicy(k8s1.25之后被替换为PodSecurity)：检查 Pod 是否符合安全策略。
  • LimitRanger：确保创建的资源符合资源限制。

• 过程：准入控制器在授权通过后执行，确保集群的安全策略、资源限制等被正确应用。

认证、鉴权和准入控制的执行顺序：

1. 认证：首先通过认证，确认请求来自于合法的用户或服务。
2. 鉴权：接着，通过 RBAC 等机制判断该用户是否有权限执行该请求。
3. 准入控制：最后，准入控制器执行，确保请求符合集群的策略要求，才最终允许该请求对资源生效。

三者的关系：

• 认证决定了"你是谁"。
• 鉴权决定了"你是否有权限做这件事"。
• 准入控制决定了"这件事是否合规，是否符合集群的策略"。

每个步骤都是互相关联的，只有通过了前面的步骤，才能进入后续的流程。

举例：

假设一个用户使用 kubectl 尝试创建一个 Pod：

1. 认证：API Server 通过用户的证书验证其身份。
2. 鉴权：RBAC 确认该用户是否有权限创建 Pod。
3. 准入控制：准入控制器检查创建的 Pod 是否符合集群的安全策略，如 Pod 安全策略或资源限制等。

这样 Kubernetes 能够确保只有合法、授权并且符合集群策略的请求才能对集群进行操作。

APIGroup

APIGroup 是 Kubernetes 中为了扩展性而引入的一种概念，它将 API 功能按逻辑分类和组织。例如，核心的 Kubernetes API 资源（如 Pod、Service）属于默认的核心 API 组，而像 Deployment、Ingress 等扩展资源则属于自定义的 API 组。每个 API 组可以包含一个或多个版本，如 v1、v1beta1。

1.APIGroup 的作用：

• 通过分组，Kubernetes 可以轻松扩展 API，支持更多的资源对象，而不影响核心功能。
• 允许同一 API 组的不同版本并存，便于开发者在新旧 API 之间进行平滑迁移。
• 清晰地区分核心 Kubernetes 资源与扩展资源。

2. APIGroup 的组成

每个 API 组通常包含以下几部分：

• Group 名称：API 组的名称，如 apps、batch、networking.k8s.io。
• 版本：每个 API 组可能包含多个版本的 API，如 v1、v1beta1。每个版本代表一组特定的资源和行为。
• 资源：API 组中的实际资源对象，如 Deployment、StatefulSet、Ingress 等。

3. APIGroup 的使用示例

在 Kubernetes 的 yaml 文件中，你经常会看到 apiVersion 字段，其格式为：<APIGroup>/<Version>，例如：

apiVersion: apps/v1
kind: Deployment

其中 apps 是 APIGroup，v1 是版本，Deployment 是资源类型。

常见的 APIGroup：

• core
  

  ：这是 Kubernetes 的核心 API 组，不需要显式指定（也就是没有 APIGroup 部分），例如

  apiVersion: v1
  

  • 包含资源：Pod、Service、ConfigMap、Secret 等。

• apps
  

  ：用于处理与应用相关的资源。

  • 版本：v1
  • 包含资源：Deployment、StatefulSet、DaemonSet 等。

• batch
  

  ：用于批处理任务。

  • 版本：v1、v1beta1
  • 包含资源：Job、CronJob。

• networking.k8s.io
  

  ：与网络相关的 API 组。

  • 版本：v1
  • 包含资源：Ingress、NetworkPolicy。