容器与Kubernetes安全第03页：认证授权与准入控制体系

01 · 认证体系

API Server的认证阶段回答"你是谁"。Kubernetes原生不提供用户管理系统，而是通过可插拔认证器对接外部身份源——这一设计既是灵活性，也是误配置的高发区。

02 · RBAC深度解析

RBAC（Role-Based Access Control）自Kubernetes v1.8起进入稳定版（GA），是事实上的授权标准。其模型由四个对象构成，理解授权判定的优先级规则是排查过度授权的前提。

2.1 四对象模型与判定规则

• deny优先于allow，allow优先于默认拒绝：RBAC只有允许规则，无显式拒绝；一个主体在任一角色上获得allow即生效。聚合规则意味着排查时必须求并集。
• 高危verb清单：escalate（权限提升）、impersonate（冒充其他主体）、bind（绑定更高权限角色）、escalate verbs组合可将低权限转化为集群管理权限——授予这些verb须等同于授予admin进行评审。
• system:*组：system:masters组默认绑定cluster-admin；system:serviceaccounts、system:authenticated等伪组范围极大，任何对其的绑定都应视为配置事故。

2.2 最小权限工程化要点

• 按"应用面→命名空间→verbs资源清单"三维生成Role，默认禁止ClusterRoleBinding；确需集群级读（如监控）使用内置的只读聚合ClusterRole并RoleBinding到指定namespace。
• 对ServiceAccount实施"按服务拆分"：一个Deployment一个SA，绝不复用default SA。
• 开启--authorization-mode=RBAC,Node，Node授权器保障kubelet仅能操作本节点资源，与RBAC互补。
• 周期性权限审查：用kubectl auth can-i以攻击者视角重放关键操作清单，输出差异报告。

03 · ServiceAccount与令牌治理

ServiceAccount（SA）是工作负载的集群内身份。其治理经历了三个阶段的演进，当前最佳实践已非常明确，但存量集群的治理欠账依然普遍。

• automountServiceAccountToken=false：不访问API的Pod（绝大多数业务容器）应显式关闭令牌自动挂载——被攻破的容器不再自带集群凭证。
• default SA最小化：default SA默认无权限（v1.24起不再自动创建配套Secret），但历史上其令牌常被误挂载；应确保无任何绑定将其与权限关联。
• 外部云身份联合：对需要访问云资源（S3、数据库）的Pod，优先使用IRSA类机制（EKS）、Workload Identity（GKE/AKS）将K8s SA映射为云IAM角色，避免云密钥进Pod——这是Capital One类元数据凭证风险的容器版解法（与子课题01协同）。

04 · 准入控制体系

准入控制器是API Server处理链中在持久化之前执行的插件链，分两类：变更型（Mutating）在校验前修改对象（如注入sidecar、默认化安全字段），校验型（Validating）仅做放行/拒绝判定。"默认安全"的工程落地，90%发生在这一层。

4.1 内置准入插件的关键项

4.2 动态准入：策略即代码的两大主流

05 · Secrets全生命周期治理

Secrets是集群内最高浓度的敏感资产，其风险贯穿存储、分发、使用、轮换、删除五个环节。治理的核心事实是：etcd默认以Base64（可逆编码而非加密）存储Secret，任何获得etcd读取能力或备份访问能力的主体都可还原全部Secret。

5.1 静态加密：EncryptionConfiguration

• apiserver通过EncryptionConfiguration配置项启用静态加密：支持aescbc、aesgcm、secretbox等本地提供者，以及通过KMS插件对接外部密钥管理服务（KMS v1自v1.10引入、自v1.28起废弃（v1.29起默认禁用），KMS v2自v1.29起稳定（GA），性能与轮换机制大幅改进）。
• 采用 envelope encryption（信封加密）模式：数据密钥加密Secret，主密钥由外部KMS保管——即使etcd数据与快照泄露，攻击者无法脱离KMS解密。
• 切换加密提供者后须执行存量数据重写（kubectl get|replace 批量触发），否则旧数据仍以旧方式存储。

5.2 分发与使用环节

• 最小化挂载：仅挂载所需Secret的特定key；优先以volume而非环境变量注入（环境变量在crash日志、/proc//environ、describe输出中更易泄露）。
• 外部化机密管理：对高价值凭证（数据库口令、TLS私钥），优先采用External Secrets Operator同步Vault/AWS Secrets Manager等外部系统，或使用Secrets Store CSI Driver实现"挂载即取、不落etcd"的模式。
• RBAC收敛：get/list secrets是顶级敏感权限；列表权限（list）在一次调用中即导出全部Secret，应严格按namespace+sa拆分。
• 轮换与失效：建立凭证轮换SOP（应用支持reload最佳）；删除Secret后若etcd未加密且快照存在，凭证仍可能从备份还原——轮换是唯一彻底的失效手段。

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:                    # KMS v2 信封加密（推荐）
          apiVersion: v2
          name: my-kms-plugin
          endpoint: unix:///var/run/kms/kms.sock
          timeout: 3s
      - aescbc:                 # 本地回退（密钥须安全分发与轮换）
          keys:
            - name: key1
              secret: <BASE64_32BYTE_KEY>
      - identity: {}            # 读取未加密旧数据用

说明：示例仅展示配置结构（截断），完整字段与KMS插件部署参见Kubernetes官方文档"Encrypting Confidential Data at Rest"。

06 · API审计日志

审计策略（Audit Policy）定义了哪些API事件被记录、以何种详细程度记录，是所有上层检测（异常行为分析、取证、合规）的原始数据源。没有审计日志的集群在事件响应中近乎"盲飞"。

• 阶段（stage）：RequestReceived、ResponseStarted、ResponseComplete、Panic四类事件；审计后端可选日志文件或Webhook（动态后端）。
• 基线策略原则：对所有"写verb + secrets/configmaps/rbac类资源"至少记录Metadata；对get/list secrets提级为Request；对系统组件高频读（leases/endpoints）设None降噪。
• 集成：审计日志经Filebeat/DaemonSet或Webhook直推SIEM/日志平台；检测规则见第7页场景库（如"非运维时段批量list secrets"）。

本节参考来源（第3页）