一.安全机制
安全机制说明
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:允许通过调用外部服务来决定是否允许某个请求。
- RBAC (Role-Based Access Control):Kubernetes 主要使用基于角色的访问控制机制。管理员通过定义
- 过程:认证通过后,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:确保创建的资源符合资源限制。
-
过程:准入控制器在授权通过后执行,确保集群的安全策略、资源限制等被正确应用。
认证、鉴权和准入控制的执行顺序:
- 认证:首先通过认证,确认请求来自于合法的用户或服务。
- 鉴权:接着,通过 RBAC 等机制判断该用户是否有权限执行该请求。
- 准入控制:最后,准入控制器执行,确保请求符合集群的策略要求,才最终允许该请求对资源生效。
三者的关系:
- 认证决定了"你是谁"。
- 鉴权决定了"你是否有权限做这件事"。
- 准入控制决定了"这件事是否合规,是否符合集群的策略"。
每个步骤都是互相关联的,只有通过了前面的步骤,才能进入后续的流程。
举例:
假设一个用户使用 kubectl
尝试创建一个 Pod:
- 认证:API Server 通过用户的证书验证其身份。
- 鉴权:RBAC 确认该用户是否有权限创建 Pod。
- 准入控制:准入控制器检查创建的 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
。
- 版本: