Kubernetes 安全管理：认证、授权与准入控制全面解析

Kubernetes（K8s）作为容器编排平台，其安全核心围绕"请求访问控制 "构建，所有对集群资源的操作均需经过kube-apiserver（集群唯一入口）的三层校验：认证（Authenticating）-->授权（Authorization）-->准入控制（Admission Control）。这一流程确保只有"身份合法、权限足够、符合规则"的请求才能执行，是集群安全的基石。

一、整体安全架构：请求的 "三道防线"

K8s采用"分层防御"思想，所有客户端（普通用户/集群内Pod）的请求必须依次通过以下三步，任一环节失败则请求被拒绝：

1.认证（身份校验）：确认"你是谁" ------ 验证客户端身份合法性（如账号、令牌、证书）。

2.授权（权限校验）：确认"你能做什么" ------ 检查已认证的客户端是否有权限操作目标资源（如创建Pod、删除ConfigMap）。

3.准入控制（规则校验）：确认"操作是否合规"------ 在资源持久化前，通过插件对请求进行额外校验或修改（如资源配额、安全策略）。

其中，客户端分为两类，认证机制略有差异：

普通用户（User Account）：面向现实中的人（如运维人员），需手动管理账号（K8s 不提供内置用户管理，需结合外部系统如 LDAP）。
服务账号（ServiceAccount）：面向集群内 Pod 中的进程（如应用程序调用 K8s API），是 K8s 内置资源，自动关联到 Pod。

二、第一道防线：认证（Authenticating）

认证的核心是"验证客户端身份"，K8s不存储用户信息，仅通过"凭证"判断身份合法性。常见认证方式和账号体系如下：

2.1 核心认证方式

K8s支持多种认证机制（可同时启用，按顺序校验），主流方式包括：

认证方式	原理	适用场景
令牌（Token）认证	客户端携带预生成的令牌（如 ServiceAccount 关联的 Secret Token），APIServer 校验令牌有效性。	Pod 内进程调用 K8s API（默认方式）。
SSL/TLS 证书认证	客户端与 APIServer 双向认证：客户端需提供 CA 签署的证书，APIServer 验证证书合法性。	运维人员通过 `kubectl` 操作集群（最安全）。
基础认证（Basic Auth）	客户端携带用户名 + 密码（存储在静态文件中），APIServer 比对校验。	测试环境（生产环境不推荐，密码易泄露）。
Webhook 认证	APIServer 将认证请求转发到外部服务（如 LDAP、OAuth2 服务），由外部服务返回认证结果。	企业级集群（对接现有身份系统）。

2.2 两类账号体系

K8s区分"用户账号"和"服务账号"，分别对应"人"和"Pod进程"的身份：

1. 服务账号（ServiceAccount）：给 Pod 用的账号

**设计目的：**为Pod内的应用程序提供访问K8s API的身份凭证（如Pod内的程序需查询其他Pod状态）。
核心特性：
- 与Namespace绑定：每个Namespace自动创建一个default ServiceAccount，Pod若未指定则默认使用该账号。
- 自动关联Secret：创建ServiceAccount时，K8s会自动生成一个包含Token和CA证书的Secret，Pod挂载该Secret即可完成认证。
操作示例：

1. 创建 ServiceAccount（命名空间 default）

kubectl create serviceaccount test-sa

2. 查看 ServiceAccount 详情（含关联的 Secret）

kubectl describe sa test-sa

输出会包含：Secrets: [test-sa-token-xxxx]

3. Pod 引用 ServiceAccount

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
serviceAccountName: test-sa # 引用自定义 ServiceAccount
containers:
- name: nginx
image: nginx:latest
EOF

2. 用户账号（User Account）：给人用的账号

设计目的：面向集群管理员、开发人员等"人"的身份，用于通过kubectl或API操作集群。
核心特性：
- 跨Namespace：用户账号不绑定Namespace，可在集群范围内使用。
- 需外部管理：K8s不提供内置的用户创建命令，需通过证书、LDAP等外部系统管理）如通过openssl生成用户证书。
配置示例（kubectl 配置文件） ：kubectl config view 可查看当前用户的认证配置，核心包含 "集群地址、用户证书 / 令牌"：

apiVersion: v1
clusters:
- cluster:
  certificate-authority-data: DATA+OMITTED # 集群 CA 证书
  server: https://192.168.40.199:6443 # APIServer 地址
  name: kubernetes
  users:
- name: kubernetes-admin # 用户名
  user:
  client-certificate-data: REDACTED # 用户证书
  client-key-data: REDACTED # 用户私钥
  contexts:
- context:
  cluster: kubernetes # 关联的集群
  user: kubernetes-admin # 关联的用户
  name: kubernetes-admin@kubernetes
  current-context: kubernetes-admin@kubernetes # 当前使用的上下文

三、第二道防线：授权（Authorization）

认证通过后，K8s需判断"该客户端是否有权限执行请求操作"，这一过程由授权插件实现。K8s 1.6+后默认推荐RBAC（基于角色的访问控制），替代了早期的ABAC、Node等插件。

3.1 主流授权插件对比

授权插件	原理	优缺点	适用场景
RBAC（推荐）	将权限定义为 "角色"，通过 "绑定" 将角色赋予用户 / ServiceAccount，灵活可控。	优点：细粒度、易维护；缺点：需手动配置角色。	生产环境（所有场景）。
ABAC	基于属性（如用户、资源、操作）的策略文件授权，策略文件修改需重启 APIServer。	优点：灵活；缺点：难维护、不支持动态更新。	测试环境。
Node	仅授权 Node 节点访问自身相关资源（如 Node 上的 Pod），由 K8s 自动管理。	优点：无需手动配置；缺点：仅适用于 Node。	节点自身权限控制。
Webhook	将授权请求转发到外部服务，由外部服务判断是否授权（如对接企业权限系统）。	优点：对接外部系统；缺点：依赖外部服务可用性。	企业级复杂权限场景。

3.2 RBAC 核心概念：4 个资源对象

RBAC的核心是"角色定义权限，绑定关联角色与用户"，包含4个内置资源对象：

资源对象	作用	作用范围
Role（角色）	定义单个 Namespace 内的权限集合（如 "读取 default 命名空间的 Pod"）。	Namespace 级别
ClusterRole（集群角色）	定义集群范围的权限集合（如 "读取所有 Namespace 的 Secret""访问 Node 资源"）。	集群级别
RoleBinding（角色绑定）	将 Role/ClusterRole 绑定到用户 / ServiceAccount，权限仅作用于单个 Namespace。	Namespace 级别
ClusterRoleBinding（集群角色绑定）	将 ClusterRole 绑定到用户 / ServiceAccount，权限作用于整个集群。

1. Role：Namespace 级别的权限定义

示例:定义一个"读取default命名空间Pod"的Role：

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader  # 角色名
  namespace: default  # 仅作用于 default 命名空间
rules:  # 权限规则列表
- apiGroups: [""]  # API 组（空字符串表示核心 API 组，如 pods、services）
  resources: ["pods"]  # 资源类型（如 pods、configmaps、deployments）
  verbs: ["get", "list", "watch"]  # 允许的操作（get：查询单个；list：查询列表；watch：监听）
  # resourceNames: ["nginx-pod"]  # 可选，限制仅对特定资源实例生效

2. ClusterRole：集群级别的权限定义

示例：定义一个"读取所有Namespace Secret"的ClusterRole：

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader  # 集群角色名（无 Namespace）
rules:
- apiGroups: [""]
  resources: ["secrets"]  # 资源类型
  verbs: ["get", "list", "watch"]  # 允许的操作

3. RoleBinding：绑定角色到用户（Namespace 级别）

示例1：将pod-reader Role绑定到用户alice（仅default命名空间生效）：

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-pod-reader
  namespace: default
subjects:  # 绑定的"主体"（用户/ServiceAccount/组）
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:  # 关联的角色（必须与 Role/ClusterRole 匹配）
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

示例 2：将 secret-reader ClusterRole 绑定到 ServiceAccount test-sa（仅 default 命名空间生效）：

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-sa-secret-reader
  namespace: default
subjects:
- kind: ServiceAccount
  name: test-sa
  namespace: default  # ServiceAccount 所在的 Namespace
roleRef:
  kind: ClusterRole  # 引用集群角色，但权限仅作用于当前 Namespace
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

4. ClusterRoleBinding：绑定集群角色到用户（集群级别）

示例：将 secret-reader ClusterRole 绑定到组 manager（所有 Namespace 生效）：

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-secret-reader
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

3.3 RBAC 常用操作命令

操作需求	命令示例
创建 Role	`kubectl create role pod-reader --verb=get,list,watch --resource=pods -n default`
创建 ClusterRole	`kubectl create clusterrole secret-reader --verb=get,list,watch --resource=secrets`
创建 RoleBinding（绑定用户）	`kubectl create rolebinding alice-pod-reader --role=pod-reader --user=alice -n default`
创建 RoleBinding（绑定 ServiceAccount）	`kubectl create rolebinding test-sa-secret-reader --clusterrole=secret-reader --serviceaccount=default:test-sa -n default`
创建 ClusterRoleBinding	`kubectl create clusterrolebinding manager-secret-reader --clusterrole=secret-reader --group=manager`
查看 Role/RoleBinding	`kubectl get role -n default`、`kubectl get rolebinding -n default -o wide`
查看 ClusterRole/ClusterRoleBinding	`kubectl get clusterrole`、`kubectl get clusterrolebinding`

四、第三道防线：准入控制（Admission Control）

授权通过后，请求进入"准入控制"阶段 ------ 由**准入控制器（Admission Controller）**对请求进行最后校验或修改，确保资源符合集群规则（如资源配额、安全策略）。只有所有准入控制器通过，请求才会被持久化到etcd。

4.1 准入控制器的核心特性

运行位置：嵌入在kube-apiserver中，需通过APIServer启动参数 --enable-admission-plugins启用（K8s 1.19+推荐用此参数替代旧的 --admission-control）。
两类操作：
- **1.Mutating(修改)：**修改请求中的资源对象（如自动为Pod注入Sidecar容器、添加标签）
- **2.Validating（验证）：**校验资源对象是否符合规则（如资源是否超过配额、是否违反安全策略）。
**执行顺序：**先执行所有Mutating控制器，再执行所有Valicating控制器

4.2 必选 / 常用准入控制器

K8s提供数十种准入控制器，生产环境需启用以下核心插件（根据版本调整）：

准入控制器名称	类型	作用
NamespaceLifecycle	Validating	禁止在不存在的 Namespace 中创建资源；删除 Namespace 时自动删除其下所有资源。
LimitRanger	Mutating+Validating	强制 Pod / 容器遵守 Namespace 中的 `LimitRange` 规则（如 CPU / 内存的默认值和上限）。
ServiceAccount	Mutating+Validating	自动为 Pod 关联 ServiceAccount；验证 Pod 引用的 ServiceAccount 存在。
ResourceQuota	Validating	强制 Namespace 遵守 `ResourceQuota` 规则（如总 CPU / 内存配额、资源对象数量上限）。
MutatingAdmissionWebhook	Mutating	允许通过外部 Webhook 服务修改资源（如 Istio 自动注入 Sidecar）。
ValidatingAdmissionWebhook	Validating	允许通过外部 Webhook 服务验证资源（如自定义安全策略校验）。
PodSecurityPolicy	Mutating+Validating	（K8s 1.25+ 已废弃，推荐用 Pod Security Standards）强制 Pod 遵守安全策略（如禁止特权容器）。
DefaultStorageClass	Mutating	为未指定 `storageClassName` 的 PVC 自动分配默认存储类。

4.3 启用准入控制器的配置示例

在kube-apiserver的启动参数中配置（如通过kubeadm部署的集群，可修改 /etc/kubernetes/manifests/kube-apiserver.yaml）:

复制代码

spec:
  containers:
  - command:
    - kube-apiserver
    # 启用核心准入控制器（1.24+ 版本示例）
    - --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,DefaultStorageClass
    # 禁用不需要的控制器（如废弃的 PodSecurityPolicy）
    - --disable-admission-plugins=PodSecurityPolicy
    # 其他参数...

五、核心总结：三层校验的逻辑闭环

K8s 安全管理的本质是 "最小权限原则"，通过三层校验确保集群资源不被未授权访问或滥用：

认证：解决 "身份合法" 问题 ------ 排除匿名请求，确认客户端是 "可信的人或 Pod"。
授权：解决 "权限足够" 问题 ------ 通过 RBAC 精细控制 "谁能操作哪些资源"，避免越权。
准入控制：解决 "操作合规" 问题 ------ 通过插件强制集群规则，避免资源配置违反安全或资源策略。

生产环境中，需重点关注：

为 ServiceAccount 授予 "最小必要权限"（避免使用 cluster-admin）。
启用核心准入控制器（尤其是 ResourceQuota、ValidatingAdmissionWebhook）。
通过 kubectl auth can-i 验证权限（如 `kubectl auth can-i create pods

点赞+收藏+关注，下期不见不散。

Kubernetes 安全管理：认证、授权与准入控制全面解析

一、整体安全架构：请求的 "三道防线"

二、第一道防线：认证（Authenticating）

2.1 核心认证方式

2.2 两类账号体系

1. 服务账号（ServiceAccount）：给 Pod 用的账号

1. 创建 ServiceAccount（命名空间 default）

2. 查看 ServiceAccount 详情（含关联的 Secret）

输出会包含：Secrets: [test-sa-token-xxxx]

3. Pod 引用 ServiceAccount

2. 用户账号（User Account）：给人用的账号

三、第二道防线：授权（Authorization）

3.1 主流授权插件对比

3.2 RBAC 核心概念：4 个资源对象

1. Role：Namespace 级别的权限定义

2. ClusterRole：集群级别的权限定义

3. RoleBinding：绑定角色到用户（Namespace 级别）

4. ClusterRoleBinding：绑定集群角色到用户（集群级别）

3.3 RBAC 常用操作命令

四、第三道防线：准入控制（Admission Control）

4.1 准入控制器的核心特性

4.2 必选 / 常用准入控制器

4.3 启用准入控制器的配置示例

五、核心总结：三层校验的逻辑闭环