Kubernetes 安全加固：RBAC、Pod Security、准入与网络隔离

实验基线：Kubernetes v1.37.0、kubectl v1.37.0。先在测试环境执行，记录变更前状态与回滚点；生产集群不得直接照抄节点地址、网段、存储类或资源额度。

请求经过哪些安全关卡

请求先认证，再授权，然后经过准入控制，最后才持久化。读取请求通常不经过准入，因此敏感资源的读权限必须由 RBAC 严格控制。不要给应用 ServiceAccount 绑定 cluster-admin。

最小权限示例

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: config-reader, namespace: lab}
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]
  verbs: ["get"]

kubectl auth can-i get configmap/app-config -n lab --as=system:serviceaccount:lab:app
kubectl auth can-i list secrets -n lab --as=system:serviceaccount:lab:app
kubectl get role,rolebinding -n lab

验收既要证明允许项成功，也要证明不允许项被拒绝。

Pod Security Admission

kubectl label namespace lab \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

先用 warn/audit 收集不兼容项，再逐步 enforce。安全上下文建议设置非 root、只读根文件系统、禁止提权、删除 Linux capabilities，并为可写目录挂载显式卷。镜像固定摘要，使用受控仓库和签名验证。

生产检查清单

限制匿名访问与高权限绑定，定期审计 RBAC。
Secret 启用静态加密并建立轮换。
命名空间默认拒绝网络，再按业务流量放行。
启用审计日志，保护 API Server 与 etcd。
升级前检查弃用 API 和第三方准入组件可用性。

建立命名空间威胁模型

列出主体（人、流水线、工作负载）、资产（Secret、配置、业务数据、节点权限）和入口（API、镜像、网络、卷）。每条权限都回答：谁、在什么命名空间、对哪种资源、能执行哪些动词、是否可升级权限。

完整 RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: {name: app-config-reader, namespace: lab}
subjects:
- kind: ServiceAccount
  name: app
  namespace: lab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: config-reader

kubectl auth can-i --list -n lab --as=system:serviceaccount:lab:app
kubectl auth can-i get configmap/app-config -n lab --as=system:serviceaccount:lab:app
kubectl auth can-i get secrets -n lab --as=system:serviceaccount:lab:app

避免通配 resources/verbs，不给应用创建 RoleBinding 的权限，否则可能形成权限提升。

受限安全上下文

spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile: {type: RuntimeDefault}
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities: {drop: ["ALL"]}

应用若需要写临时文件，挂载 emptyDir 到明确目录，而不是关闭只读根文件系统。镜像中的用户必须是非零 UID，不能只写 runAsNonRoot 而不验证镜像。

PSA 安全迁移步骤

在测试命名空间加 restricted 的 warn/audit 标签。
收集违规 Pod，按工作负载逐一修复。
在低风险命名空间启用 enforce=baseline。
逐步提升到 restricted，并保留版本标签。
给确需例外的系统工作负载建立独立命名空间与书面理由。

供应链与运行时检查

镜像使用摘要固定，扫描漏洞并验证来源。
限制 privileged、hostNetwork、hostPID、hostPath。
API Server/etcd 使用 TLS，etcd 数据静态加密。
审计 cluster-admin、impersonate、bind、escalate 权限。
默认拒绝网络，显式放行 DNS 和业务依赖。

安全验收必须包含负向测试：未经授权的读取、创建特权 Pod、访问隔离服务都应失败。

审计高风险权限

kubectl get clusterrolebinding -o wide
kubectl get rolebinding -A -o wide
kubectl auth can-i impersonate users --as=<subject>
kubectl auth can-i create clusterrolebindings --as=<subject>

重点审查 secrets 读取、pods/exec、pods/attach、serviceaccounts/token、impersonate、bind、escalate、nodes/proxy 和 webhook 配置权限。pods/exec 等价于进入工作负载，可能读取挂载的秘密。

Break-glass 管理员流程

日常账号无 cluster-admin。
紧急凭据离线/受强认证保护，启用有工单和双人审批。
使用时间受限，所有操作进入审计日志。
事件结束立即撤销会话并轮换凭据。
复盘是否能用更小权限的预定义角色替代。

策略上线验证

准备一组应被拒绝的清单：特权容器、hostPath、hostNetwork、root 用户、允许提权；以及一组符合 restricted 的清单。分别执行 server dry-run，确认拒绝原因清晰。Webhook 故障策略要按风险选择 Fail 或 Ignore，并为 webhook 本身配置多副本、PDB 和超时。

kubectl apply --dry-run=server -f privileged-pod.yaml
kubectl apply --dry-run=server -f restricted-pod.yaml
kubectl get events -n lab --sort-by=.metadata.creationTimestamp

可复现记录模板

每次实验记录：集群版本、容器运行时、CNI/CSI 版本、命名空间、使用的 YAML Git 提交、开始与结束时间。命令输出至少保留对象状态、事件、关键日志和回滚结果。文中的占位符必须替换成自己的值，生产执行前应由第二人复核。

故障处理原则

先缩小影响面，不删除现场。
按对象状态—事件—日志—依赖顺序收集证据。
提出可证伪假设，一次只改变一个变量。
验证恢复后清理临时权限、调试 Pod、端口转发和测试数据。

完成检查

命令退出码为 0，目标对象状态与预期一致。
保存执行前后 YAML、事件与关键日志，确认没有把测试命名空间以外的对象改动。
故障演练完成后执行清理或回滚，再进行下一章。