上一篇【第51篇】K8s网络故障排查指南——Pod不通了别慌按这条“黄金路径“走下一篇【第53篇】RBAC——基于角色的访问控制完全指南摘要前面聊了网络——怎么让Pod能通、能隔离。但有个更根本的问题谁有权限动我的集群K8s里所有操作都经过API Server这一个总闸。你敲的每条kubectl、每个Operator的每次调谐、每个控制器的每次LIST/WATCH都是发往API Server的HTTP请求。如果这扇门没守好前面网络做得再漂亮也是白搭。K8s在API Server里设了四道关卡TLS加密通道 → Authentication你是谁→ Authorization你能干啥→ Admission Control最后一道体检。这篇文章用一条安检流水线把整个安全模型串起来让你知道每个请求在进K8s之前要过哪几关。一、请求的完整旅程1.1 安检流水线全景【一个 kubectl 请求的安检流水线】 kubectl apply -f pod.yaml │ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡0: TLS 传输加密 │ │ • 客户端和API Server之间的HTTPS │ │ • 双向证书校验(mTLS)防中间人 │ └─────────────────────────┬──────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡1: Authentication (认证) │ │ 你是谁 —— 验证身份 │ │ 方式: X509证书 / Bearer Token / ServiceAccount / Webhook│ └─────────────────────────┬──────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡2: Authorization (授权) │ │ 你能干这个吗 —— 验证权限 │ │ 方式: RBAC(主流) / ABAC / Node / Webhook │ └─────────────────────────┬──────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡3: Admission Control (准入控制) │ │ 最后体检 —— 改请求/拒请求 │ │ 方式: MutatingWebhook / ValidatingWebhook / 内置插件 │ └─────────────────────────┬──────────────────────────────┘ ▼ 通过写入 etcd要点记住这个顺序——先认身份(AuthN)再查权限(AuthZ)最后做体检(Admission)。任何一道关卡说不行请求就被拒。而且三道关卡各管各的认证只回答你是谁返回一个username授权基于这个身份查能不能干准入控制则可以不看身份、直接根据请求内容决定放行还是改写。二、关卡1Authentication你是谁2.1 四种认证方式【K8s 认证方式对比】 ┌─────────────────────────────────────────────────────┐ │ 1. X509 客户端证书 (kubectl/管理员最常用) │ │ • 证书里带 CNxxx (用户名), Oxxx (组) │ │ • API Server用CA验证证书真伪 │ │ • kubectl的~/.kube/config就是这玩意 │ ├─────────────────────────────────────────────────────┤ │ 2. Bearer Token (ServiceAccount/手动token) │ │ • HTTP Header里带 Authorization: Bearer token │ │ • Pod里的/var/run/secrets/kubernetes.io/serviceaccount│ ├─────────────────────────────────────────────────────┤ │ 3. ServiceAccount Token (Pod自动挂载) │ │ • 最常用每个Pod默认有个身份 │ ├─────────────────────────────────────────────────────┤ │ 4. Webhook / 外部认证 (对接公司SSO/OIDC) │ │ • 请求转发给外部认证服务判断 │ └─────────────────────────────────────────────────────┘# 看你的kubectl用的是哪种认证kubectl config view--minify# 会看到:# users:# - name: my-user# user:# client-certificate-data: ... ← X509证书方式# 或# token: xxxx ← Bearer Token方式2.2 匿名请求【匿名用户——不报身份也能进】 K8s有个特殊用户: system:anonymous • 不带任何凭证的请求 → 被识别为匿名用户 • 默认匿名用户几乎没权限(被RBAC拒) • 但某些系统API(如健康检查/版本)允许匿名读 ⚠️ 生产建议: 关闭匿名访问 --anonymous-authfalse (API Server参数)三、关卡2Authorization你能干啥3.1 RBAC是绝对主流K8s支持多种授权模式但RBAC是事实标准。它的核心三角关系【RBAC 三角关系——谁(Subject)被绑了什么角色(Role)就能干啥】 ┌──────────────┐ │ Subject │ (谁) │ User/Group/ │ │ ServiceAccount│ └──────┬───────┘ │ 被绑定 (RoleBinding) ▼ ┌──────────────┐ │ Role │ (能干啥) │ 一组权限规则 │ │ rules: │ │ - apiGroups │ │ - resources │ │ - verbs │ └──────────────┘ Role 能做什么操作的声明 RoleBinding 把Role赋给某个Subject的动作 Subject 谁来用这个Role授权模式说明现状RBAC基于角色最灵活✅ 主流默认ABAC基于属性配置文件写死❌ 基本淘汰Node专给kubelet用内置Webhook转发给外部鉴权服务特殊场景3.2 一个RBAC规则长啥样apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:prodname:pod-readerrules:-apiGroups:[]# 核心API组(空字符串)resources:[pods]# 资源类型verbs:[get,list]# 允许的动作要点RBAC的最小权限原则核心就三个词——Subject(谁)、Role(能干啥)、Binding(绑一起)。权限规则极其细粒度可以精确到只允许get/list pods不允许delete可以精确到某个namespace甚至某个resourceName。下一篇我们会把RBAC拆个底朝天。四、关卡3Admission Control最后体检4.1 它和前两者不一样认证和授权只能放行/拒绝。Admission Control还能**“改写请求”**——这是它最厉害的地方。【Admission 的两类Webhook】 Mutating (变异/改写) —— 先跑 • 可以修改请求内容 • 典型: 给Pod自动注入Sidecar(Istio)、自动加label • 例: 你没写imagePullSecrets它给你补上 Validating (校验) —— 后跑 • 只能放行/拒绝不能改 • 典型: 阻止特权容器、强制资源限制、镜像来源检查 • 例: 发现用了latest标签 → 拒绝4.2 内置的准入插件# API Server 启用的准入插件(部分)--enable-admission-pluginsNodeRestriction,LimitRanger, ResourceQuota,ServiceAccount,PodSecurity,ValidatingAdmissionPolicy# 几个关键的# NodeRestriction → 防止kubelet篡改其他Node的资源# LimitRanger → 强制默认资源限制# ResourceQuota → 检查是否超配额# PodSecurity → 强制Pod安全标准(替代PSP)# ServiceAccount → 自动挂载SA token五、安全纵深防御5.1 别只靠一道墙【K8s 安全的洋葱模型】 外层: 网络安全 (NetworkPolicy隔离) ↓ 大门: API Server 四道关卡 (TLS/AuthN/AuthZ/Admission) ↓ 身份: ServiceAccount / RBAC 最小权限 ↓ 容器: SecurityContext (非root/只读根fs) ↓ 运行时: Pod Security Standards / seccomp ↓ 数据: Secret加密 / etcd加密要点K8s安全不是配好RBAC就完事。它是层层设防的洋葱模型——网络层隔离、API层认证授权、身份层最小权限、容器层降权、数据层加密。任何一层被突破其他层还能兜底。后面几篇我们会逐个拆开RBAC、ServiceAccount、SecurityContext、NetworkPolicy安全实战、Secret管理、Pod安全标准、安全审计。本篇小结K8s的安全闸门在API Server一个请求要经过四道关卡TLS加密→Authentication认身份→Authorization查权限→Admission做体检。前三道分别回答你是谁、你能干啥、这请求合不合规其中Admission还能改写请求注入Sidecar、强制限制。RBAC是授权的绝对主流核心是Subject-Role-Binding三角。安全是纵深防御别指望一道墙挡所有。下一篇咱们把RBAC这块主城墙彻底拆明白。上一篇【第51篇】K8s网络故障排查指南——Pod不通了别慌按这条“黄金路径“走下一篇【第53篇】RBAC——基于角色的访问控制完全指南
【Kubernetes从入门到精通】第52篇：K8s安全体系全景——AuthN/AuthZ/Admission三道防线，API Server的“安检流水线“
上一篇【第51篇】K8s网络故障排查指南——Pod不通了别慌按这条“黄金路径“走下一篇【第53篇】RBAC——基于角色的访问控制完全指南摘要前面聊了网络——怎么让Pod能通、能隔离。但有个更根本的问题谁有权限动我的集群K8s里所有操作都经过API Server这一个总闸。你敲的每条kubectl、每个Operator的每次调谐、每个控制器的每次LIST/WATCH都是发往API Server的HTTP请求。如果这扇门没守好前面网络做得再漂亮也是白搭。K8s在API Server里设了四道关卡TLS加密通道 → Authentication你是谁→ Authorization你能干啥→ Admission Control最后一道体检。这篇文章用一条安检流水线把整个安全模型串起来让你知道每个请求在进K8s之前要过哪几关。一、请求的完整旅程1.1 安检流水线全景【一个 kubectl 请求的安检流水线】 kubectl apply -f pod.yaml │ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡0: TLS 传输加密 │ │ • 客户端和API Server之间的HTTPS │ │ • 双向证书校验(mTLS)防中间人 │ └─────────────────────────┬──────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡1: Authentication (认证) │ │ 你是谁 —— 验证身份 │ │ 方式: X509证书 / Bearer Token / ServiceAccount / Webhook│ └─────────────────────────┬──────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡2: Authorization (授权) │ │ 你能干这个吗 —— 验证权限 │ │ 方式: RBAC(主流) / ABAC / Node / Webhook │ └─────────────────────────┬──────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ 关卡3: Admission Control (准入控制) │ │ 最后体检 —— 改请求/拒请求 │ │ 方式: MutatingWebhook / ValidatingWebhook / 内置插件 │ └─────────────────────────┬──────────────────────────────┘ ▼ 通过写入 etcd要点记住这个顺序——先认身份(AuthN)再查权限(AuthZ)最后做体检(Admission)。任何一道关卡说不行请求就被拒。而且三道关卡各管各的认证只回答你是谁返回一个username授权基于这个身份查能不能干准入控制则可以不看身份、直接根据请求内容决定放行还是改写。二、关卡1Authentication你是谁2.1 四种认证方式【K8s 认证方式对比】 ┌─────────────────────────────────────────────────────┐ │ 1. X509 客户端证书 (kubectl/管理员最常用) │ │ • 证书里带 CNxxx (用户名), Oxxx (组) │ │ • API Server用CA验证证书真伪 │ │ • kubectl的~/.kube/config就是这玩意 │ ├─────────────────────────────────────────────────────┤ │ 2. Bearer Token (ServiceAccount/手动token) │ │ • HTTP Header里带 Authorization: Bearer token │ │ • Pod里的/var/run/secrets/kubernetes.io/serviceaccount│ ├─────────────────────────────────────────────────────┤ │ 3. ServiceAccount Token (Pod自动挂载) │ │ • 最常用每个Pod默认有个身份 │ ├─────────────────────────────────────────────────────┤ │ 4. Webhook / 外部认证 (对接公司SSO/OIDC) │ │ • 请求转发给外部认证服务判断 │ └─────────────────────────────────────────────────────┘# 看你的kubectl用的是哪种认证kubectl config view--minify# 会看到:# users:# - name: my-user# user:# client-certificate-data: ... ← X509证书方式# 或# token: xxxx ← Bearer Token方式2.2 匿名请求【匿名用户——不报身份也能进】 K8s有个特殊用户: system:anonymous • 不带任何凭证的请求 → 被识别为匿名用户 • 默认匿名用户几乎没权限(被RBAC拒) • 但某些系统API(如健康检查/版本)允许匿名读 ⚠️ 生产建议: 关闭匿名访问 --anonymous-authfalse (API Server参数)三、关卡2Authorization你能干啥3.1 RBAC是绝对主流K8s支持多种授权模式但RBAC是事实标准。它的核心三角关系【RBAC 三角关系——谁(Subject)被绑了什么角色(Role)就能干啥】 ┌──────────────┐ │ Subject │ (谁) │ User/Group/ │ │ ServiceAccount│ └──────┬───────┘ │ 被绑定 (RoleBinding) ▼ ┌──────────────┐ │ Role │ (能干啥) │ 一组权限规则 │ │ rules: │ │ - apiGroups │ │ - resources │ │ - verbs │ └──────────────┘ Role 能做什么操作的声明 RoleBinding 把Role赋给某个Subject的动作 Subject 谁来用这个Role授权模式说明现状RBAC基于角色最灵活✅ 主流默认ABAC基于属性配置文件写死❌ 基本淘汰Node专给kubelet用内置Webhook转发给外部鉴权服务特殊场景3.2 一个RBAC规则长啥样apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:prodname:pod-readerrules:-apiGroups:[]# 核心API组(空字符串)resources:[pods]# 资源类型verbs:[get,list]# 允许的动作要点RBAC的最小权限原则核心就三个词——Subject(谁)、Role(能干啥)、Binding(绑一起)。权限规则极其细粒度可以精确到只允许get/list pods不允许delete可以精确到某个namespace甚至某个resourceName。下一篇我们会把RBAC拆个底朝天。四、关卡3Admission Control最后体检4.1 它和前两者不一样认证和授权只能放行/拒绝。Admission Control还能**“改写请求”**——这是它最厉害的地方。【Admission 的两类Webhook】 Mutating (变异/改写) —— 先跑 • 可以修改请求内容 • 典型: 给Pod自动注入Sidecar(Istio)、自动加label • 例: 你没写imagePullSecrets它给你补上 Validating (校验) —— 后跑 • 只能放行/拒绝不能改 • 典型: 阻止特权容器、强制资源限制、镜像来源检查 • 例: 发现用了latest标签 → 拒绝4.2 内置的准入插件# API Server 启用的准入插件(部分)--enable-admission-pluginsNodeRestriction,LimitRanger, ResourceQuota,ServiceAccount,PodSecurity,ValidatingAdmissionPolicy# 几个关键的# NodeRestriction → 防止kubelet篡改其他Node的资源# LimitRanger → 强制默认资源限制# ResourceQuota → 检查是否超配额# PodSecurity → 强制Pod安全标准(替代PSP)# ServiceAccount → 自动挂载SA token五、安全纵深防御5.1 别只靠一道墙【K8s 安全的洋葱模型】 外层: 网络安全 (NetworkPolicy隔离) ↓ 大门: API Server 四道关卡 (TLS/AuthN/AuthZ/Admission) ↓ 身份: ServiceAccount / RBAC 最小权限 ↓ 容器: SecurityContext (非root/只读根fs) ↓ 运行时: Pod Security Standards / seccomp ↓ 数据: Secret加密 / etcd加密要点K8s安全不是配好RBAC就完事。它是层层设防的洋葱模型——网络层隔离、API层认证授权、身份层最小权限、容器层降权、数据层加密。任何一层被突破其他层还能兜底。后面几篇我们会逐个拆开RBAC、ServiceAccount、SecurityContext、NetworkPolicy安全实战、Secret管理、Pod安全标准、安全审计。本篇小结K8s的安全闸门在API Server一个请求要经过四道关卡TLS加密→Authentication认身份→Authorization查权限→Admission做体检。前三道分别回答你是谁、你能干啥、这请求合不合规其中Admission还能改写请求注入Sidecar、强制限制。RBAC是授权的绝对主流核心是Subject-Role-Binding三角。安全是纵深防御别指望一道墙挡所有。下一篇咱们把RBAC这块主城墙彻底拆明白。上一篇【第51篇】K8s网络故障排查指南——Pod不通了别慌按这条“黄金路径“走下一篇【第53篇】RBAC——基于角色的访问控制完全指南
