当前位置： 首页 > news >正文

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

news 2025/9/28 5:11:34

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  # 引用自定义 ServiceAccountcontainers:- name: nginximage: 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-readernamespace: default
subjects:  # 绑定的“主体”（用户/ServiceAccount/组）
- kind: Username: aliceapiGroup: rbac.authorization.k8s.io
roleRef:  # 关联的角色（必须与 Role/ClusterRole 匹配）kind: Rolename: pod-readerapiGroup: 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-readernamespace: default
subjects:
- kind: ServiceAccountname: test-sanamespace: default  # ServiceAccount 所在的 Namespace
roleRef:kind: ClusterRole  # 引用集群角色，但权限仅作用于当前 Namespacename: secret-readerapiGroup: 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: Groupname: managerapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.io

3.3 RBAC 常用操作命令

操作需求命令示例
创建 Rolekubectl create role pod-reader --verb=get,list,watch --resource=pods -n default
创建 ClusterRolekubectl 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
创建 ClusterRoleBindingkubectl create clusterrolebinding manager-secret-reader --clusterrole=secret-reader --group=manager
查看 Role/RoleBindingkubectl get role -n default、kubectl get rolebinding -n default -o wide
查看 ClusterRole/ClusterRoleBindingkubectl 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提供数十种准入控制器，生产环境需启用以下核心插件（根据版本调整）：

准入控制器名称类型作用
NamespaceLifecycleValidating禁止在不存在的 Namespace 中创建资源；删除 Namespace 时自动删除其下所有资源。
LimitRangerMutating+Validating强制 Pod / 容器遵守 Namespace 中的 LimitRange 规则（如 CPU / 内存的默认值和上限）。
ServiceAccountMutating+Validating自动为 Pod 关联 ServiceAccount；验证 Pod 引用的 ServiceAccount 存在。
ResourceQuotaValidating强制 Namespace 遵守 ResourceQuota 规则（如总 CPU / 内存配额、资源对象数量上限）。
MutatingAdmissionWebhookMutating允许通过外部 Webhook 服务修改资源（如 Istio 自动注入 Sidecar）。
ValidatingAdmissionWebhookValidating允许通过外部 Webhook 服务验证资源（如自定义安全策略校验）。
PodSecurityPolicyMutating+Validating（K8s 1.25+ 已废弃，推荐用 Pod Security Standards）强制 Pod 遵守安全策略（如禁止特权容器）。
DefaultStorageClassMutating为未指定 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 安全管理的本质是 “最小权限原则”，通过三层校验确保集群资源不被未授权访问或滥用：

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

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

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

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

http://www.dtcms.com/a/414160.html

相关文章：

  • 江苏省住房城乡建设厅门户网站淄博企业网站
  • SpringBoot整合JakartaMail，实现发送邮箱功能
  • 开发 Flutter Windows 应用，如何安装工具链工具链和SDK
  • 杂记 10
  • 错误解决：Flutter找不到合适的Visual Studio 工具链
  • 基于KingbaseES集群管理实战：从部署运维到高可用架构深度解析
  • NXP - 用MCUXpresso IDE v25.6.136的工具链编译Smoothieware固件工程
  • 【影刀RPA】手机应用自动化
  • 有什么字体设计网站网站建设中的安全问题
  • 【开题答辩全过程】以 SpringBoot房屋出租管理系统为例，包含答辩的问题和答案
  • QT6中Column View与QUndoView功能与用法
  • Layui 使用
  • 如何优化 C# MVC 应用程序的性能
  • Uni-App 页面跳转监控实战：快速定位路由问题
  • Redisson的Lock和TryLock的区别
  • VLA技术论文阅读
  • find数组方法详解||Vue3 + uni-app + Wot Design（wd-picker）使用自定义插槽内容写一个下拉选择器
  • 怎么找做网站平台公司技术支持 湖北网站建设
  • 大型活动临时组网的技术解析：如何实现高效稳定的通信网络
  • 个人博客网站实验报告wordpress 页面新建
  • ZYNQ CAN接口全面解析：从裸机驱动到PetaLinux实战
  • AI 重构实体经济：2025 传统产业转型的实践与启示
  • 安宝特产品丨FME Realize：重构数据与现实的边界，让空间计算赋能现场决策
  • 第二篇: `nvidia-smi` (下) - 自动化监控与脚本
  • 配音与字幕不同步？音视频协同生成的技术原理与落地实践
  • p2p信贷网站建设永州网站建设优化
  • 批次标准化学习（第十六周周报）
  • .NET Core 中 System.Text.Json 与 Newtonsoft.Json 深度对比：用法、性能与场景选型
  • 高通平台 WLAN学习-- 性能优化优化实践：从代码层面解析 P2P 连接性能提升方案
  • 企业应该如何建设网站建立网站的信息集成过程