容器与Kubernetes安全第04页：Pod安全标准与运行时防护

01 · 容器隔离机制基础

容器不是虚拟化技术，而是一组Linux内核特性的组合装配。理解每一层机制的隔离强度与局限，是评估"这个Pod配置能挡住什么"的前提。

02 · PSS三档详解

PodSecurityPolicy（PSP）于Kubernetes v1.25正式移除后，Pod Security Standards（PSS）经内置PodSecurity准入插件成为官方唯一的Pod安全基线执行机制。PSS按namespace标签三档强制执行：

2.1 强制执行模式与标签体系

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
    # 系统命名空间（如 kube-system）则显式标注：
    # pod-security.kubernetes.io/enforce: privileged

• 三种模式：enforce（拒绝违规Pod）、audit（记录审计事件不拦截）、warn（向用户返回警告）——上线新档位建议按 audit→warn→enforce 灰度。
• 豁免机制：用户、RuntimeClass与镜像前缀可豁免（如kube-system组件）；豁免清单是基线核查重点对象。
• 与PSA的关系：PSS是标准定义，PSA（Pod Security Admission）是执行插件；第三方Webhook（Kyverno/Gatekeeper）可实现更细粒度（如按镜像仓库、按团队）的例外管理。

2.2 Baseline vs Restricted 关键差异速查

03 · 安全上下文最佳实践

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      serviceAccountName: app-sa            # 专用SA，默认不挂载令牌视需要
      automountServiceAccountToken: false   # 不访问API则关闭
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        fsGroup: 10001
        seccompProfile: { type: RuntimeDefault }
      containers:
      - name: app
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true       # 根文件系统只读，防落盘篡改
          capabilities: { drop: ["ALL"] }    # 只按需加回（如NET_BIND_SERVICE）
        volumeMounts:
        - { name: tmp, mountPath: /tmp }     # 可写目录以emptyDir提供

• readOnlyRootFilesystem：将镜像内根文件系统只读化，多数Webshell落地、配置文件篡改、恶意ELF落盘将被直接阻断；须为/tmp、缓存目录配置emptyDir。
• no-new-privileges：禁止进程通过setuid二进制提权——直接消解CVE-2022-0492类依赖setuid的逃逸链的关键环节。
• 以UID显式运行：runAsUser与镜像内USER指令双保险；避免以0（root）运行，即使逃逸后的可利用权限面也大幅收缩。
• 宿主命名空间隔离：hostNetwork/hostPID/hostIPC三者为Baseline档禁止项——开启hostPID即可看到并操作宿主机全部进程，隔离归零。

04 · 容器逃逸漏洞谱系与防护映射

将第2页漏洞档案中的运行时类逃逸事件按"机理"归类，可得到四条谱系线。每一类均有对应的基线拦截点——这正是PSS与安全上下文的价值所在。

05 · 沙箱化运行时选型

当负载不可信程度超过"共享内核"可承受边界时，应升级隔离模型。Kubernetes通过RuntimeClass资源原生支持为指定Pod选择不同运行时。

• 选型逻辑：先以PSS基线+运行时检测覆盖"可信负载"；对不受信负载按"开销敏感度"选gVisor（低开销优先）或Kata（隔离强度优先）；GPU等专用设备场景注意gVisor的设备支持边界。
• 落地形态：RuntimeClass+节点选择器将沙箱Pod调度至专用节点池；配合准入策略实现"namespace→RuntimeClass"的强制映射（如tenant命名空间强制gVisor）。
• 清醒认识：沙箱缓解的是"内核共享面"，不替代权限最小化——gVisor逃逸漏洞（其安全公告中亦有披露）与配置错误仍是独立风险。

06 · 运行时行为检测

补丁有窗口期、基线有例外项——运行时检测是兜底层。核心工具链均以eBPF或内核模块为底座，实现"无代理、低开销"的容器行为观测。

6.1 两大开源检测引擎

6.2 关键检测场景与数据源映射

本节参考来源（第4页）