容器安全加固深度实战：从内核隔离到零信任供应链的全栈防护体系

容器技术彻底改变了现代软件的交付方式，从 Docker 的兴起再到 Kubernetes 成为编排标准，云原生架构已经成为企业数字化转型的核心基础设施。然而，容器安全却始终是一个被严重低估的领域。2024 年 CrowdStrike 报告显示，容器相关安全事件同比增长 37%，而 Snyk 的调查发现超过 60% 的生产容器镜像存在高危漏洞。本文将从 Linux 内核安全机制出发，系统性地剖析容器安全的技术栈，涵盖 Namespace 隔离加固、Capabilities 精细管控、Seccomp 系统调用过滤、SELinux/AppArmor 强制访问控制、镜像签名与验证、Pod Security Admission、网络策略、运行时威胁检测、供应链安全以及零信任架构下的容器防护策略，构建一套完整的生产级容器安全加固体系。

1. 容器隔离本质：Namespace 与 Cgroup 的安全边界

容器的安全性建立在 Linux 内核的两大基础机制之上：Namespace（命名空间） 提供视图隔离，Cgroup（控制组） 提供资源限制。理解它们的局限性是加固容器安全的第一步。

Namespace 隔离的七层防护

Linux 内核提供了 7 种 Namespace，容器运行时通常使用其中 6 种：

• PID Namespace： 隔离进程 ID 空间，容器内看不到宿主机进程。但 /proc 挂载不当可能泄露宿主机进程信息
• NET Namespace： 隔离网络设备、协议栈、路由表、iptables 规则，每个容器获得独立的网络视图
• MNT Namespace： 隔离文件系统挂载点，是容器镜像分层存储的基础
• UTS Namespace： 允许容器拥有独立的主机名（hostname）
• IPC Namespace： 隔离 System V IPC 对象（信号量、消息队列、共享内存段）
• USER Namespace： 隔离用户和组 ID 映射，这是容器安全加固中最关键的 Namespace
• TIME Namespace： （Linux 5.6+）允许容器拥有独立的系统时间视图

USER Namespace — 根权限解耦

传统容器以 root 用户运行时，容器内的 UID 0 直接映射到宿主机的 UID 0，这意味着容器逃逸即获得宿主机 root 权限。User Namespace 通过 UID/GID 映射表解决了这个问题：

# /etc/subuid 和 /etc/subgid 定义映射范围
# dockremap:100000:65536
# 含义：容器内 UID 0 映射到宿主机 UID 100000
# 容器内 UID 1 映射到宿主机 UID 100001
# ...以此类推共 65536 个 UID

# 验证映射关系
$ podman run --userns=auto cat /proc/self/uid_map
         0     100000      65536

启用 USER Namespace 后，即使容器内进程以 "root"（UID 0）运行，在宿主机上它只是一个普通非特权用户。这种权限去特权化（Unprivileging）是纵深防御的第一道关键屏障。

Cgroup v2 的安全增强

Cgroup v2 不仅统一了资源控制层次结构，还引入了多项安全增强特性：

• 线程模式（Thread Mode）： 允许对单个线程进行细粒度资源控制，防止线程级 DoS
• BPF 程序挂载： 可在 cgroup 上挂载 eBPF 程序进行设备访问控制（cgroup/bpf）
• 压力阻塞信息（PSI）： 提供精确的资源压力指标，可用于自动安全防护
• 递归资源统计： 子 cgroup 的资源使用自动汇总到父 cgroup，便于审计

2. Linux Capabilities：精细化权限切割

传统的 Unix 权限模型只有 root 和非 root 的二元划分，Linux Capabilities 将 root 超级权限分解为 40+ 个独立的权限单元，实现最小权限原则（Principle of Least Privilege）。

Capabilities 的安全威胁模型

Docker 默认会保留以下 Capabilities，每一个都可能成为容器逃逸的跳板：

• CAP_SYS_ADMIN： "万能能力"，允许挂载文件系统、加载内核模块、创建设备节点。这是最危险的 Capability，拥有它几乎等于半只脚踏出容器
• CAP_NET_ADMIN： 网络接口配置、iptables 规则修改、路由表操纵，可用于网络中间人攻击
• CAP_SYS_PTRACE： 可 ptrace 任意进程，是宿主机进程注入的关键能力
• CAP_SYS_MODULE： 允许加载/卸载内核模块，直接威胁宿主机内核安全
• CAP_SYS_RAWIO： 允许原始 I/O 端口访问，可直接操作硬件
• CAP_DAC_READ_SEARCH： 绕过文件读权限检查，可读取宿主机任意文件
• CAP_SYS_BOOT： 允许重启系统，可用于触发内核崩溃转储获取敏感信息

Capabilities 加固实战

# 加固策略：drop 所有非必要 Capabilities，按需添加
# docker-compose.yml
services:
  web:
    image: nginx:alpine
    cap_drop:
      - ALL                # 删除所有 Capabilities
    cap_add:
      - NET_BIND_SERVICE   # 仅保留绑定低端口能力（如需）
      - CHOWN              # 文件属主变更（应用需要）
    security_opt:
      - no-new-privileges:true  # 禁止进程获取新权限

Kubernetes 中的等价配置使用 securityContext：

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
spec:
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      capabilities:
        drop:
          - ALL
        add: []  # 不添加任何额外 Capability
      allowPrivilegeEscalation: false  # 禁止提权
      readOnlyRootFilesystem: true     # 只读根文件系统
      runAsNonRoot: true               # 强制非 root 运行
      runAsUser: 1000
      runAsGroup: 3000
      seccompProfile:
        type: RuntimeDefault           # 启用默认 Seccomp 配置

3. Seccomp：系统调用白名单机制

Seccomp（Secure Computing Mode）是 Linux 内核提供的系统调用过滤机制。容器默认可用的系统调用约有 300+ 个，但一个典型的 Web 应用可能只需要其中不到 40 个。通过 Seccomp profile 限制可用系统调用，可以大幅缩小攻击面。

Seccomp 的工作原理

Seccomp 通过 eBPF 过滤器在内核态对 syscall 指令进行拦截和过滤。当进程尝试执行被禁止的系统调用时，内核可以配置为终止进程（SECCOMP_RET_KILL）、返回错误（SECCOMP_RET_ERRNO）或记录日志（SECCOMP_RET_LOG）。这种过滤发生在内核态，用户态无法绕过。

容器运行时 Seccomp 配置

Docker 和 containerd 默认使用一套经过充分测试的 Seccomp profile，禁用了约 44 个危险系统调用，包括：

• kexec_load / kexec_file_load： 加载新内核，可覆盖当前内核
• open_by_handle_at： 通过文件句柄打开文件，可绕过路径检查
• init_module / finit_module： 加载内核模块
• delete_module： 卸载内核模块
• ioperm / iopl： I/O 端口权限操作
• swapon / swapoff： 交换分区控制
• reboot： 系统重启
• nfsservctl： NFS 服务控制（已废弃但仍可利用）
• clock_settime / clock_adjtime： 系统时钟修改
• bpf： 加载 eBPF 程序（限制 BPF 的使用场景）

自定义 Seccomp Profile 实战

对于有特殊需求的应用（如需要 ptrace 的调试工具），可以编写自定义 Seccomp profile：

// custom-seccomp.json
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "archMap": [
    {
      "architecture": "SCMP_ARCH_X86_64",
      "subArchitectures": ["SCMP_ARCH_X86", "SCMP_ARCH_X32"]
    }
  ],
  "syscalls": [
    {
      "names": [
        "accept", "accept4", "bind", "brk", "clock_gettime",
        "clone", "close", "connect", "dup", "epoll_create1",
        "epoll_ctl", "epoll_wait", "execve", "exit_group",
        "fchown", "fcntl", "fstat", "futex", "getdents64",
        "getegid", "geteuid", "getgid", "getpid", "getppid",
        "getsockname", "getsockopt", "ioctl", "listen", "lseek",
        "madvise", "mmap", "mprotect", "munmap", "nanosleep",
        "newfstatat", "openat", "poll", "pread64", "pwrite64",
        "read", "readlink", "recvfrom", "rt_sigaction",
        "rt_sigprocmask", "rt_sigreturn", "select", "sendto",
        "set_robust_list", "set_tid_address", "setsockopt",
        "shutdown", "sigaltstack", "socket", "statfs",
        "tgkill", "uname", "unlink", "wait4", "write", "writev"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

部署时引用自定义 profile：

docker run --security-opt seccomp=custom-seccomp.json myapp:latest

4. SELinux & AppArmor：强制访问控制

Capabilities 和 Seccomp 都基于"允许/禁止"的模型，而强制访问控制（MAC）系统则提供更精细、更灵活的访问策略。Red Hat 系使用 SELinux（Security-Enhanced Linux），Debian/Ubuntu 系使用 AppArmor。

SELinux 的容器实践

SELinux 基于"类型强制"（Type Enforcement）模型，每个进程和文件都有一个安全上下文（Security Context），格式为 user:role:type:level。对于容器，关键字段是 type：

• container_t： 容器进程默认类型
• container_file_t： 容器文件/目录默认类型
• svirt_sandbox_file_t： 虚拟机/容器共享文件类型
• container_var_lib_t： 容器持久化数据

# 查看容器进程的 SELinux 上下文
$ ps -eZ | grep container
system_u:system_r:container_t:s0:c123,c456  12345 ?  00:00:01 myapp

# 查看挂载卷的上下文
$ ls -Z /var/lib/containers/volumes/mydata
system_u:object_r:container_file_t:s0:c123,c456  file1

# 关键参数：-v 挂载时添加 :z（共享标签）或 :Z（私有标签）
docker run -v /host/data:/data:Z myapp  # 私有标签，仅该容器可访问

SELinux 的 MLS/MCS（多级安全/多级分类）机制通过 category（c123,c456）实现了容器间的强制隔离 — 不同 category 的容器进程互相无法访问对方的文件。

AppArmor 的容器实践

AppArmor 基于路径的访问控制，语法更直观：

# /etc/apparmor.d/containers/docker-default（Docker 默认 profile 片段）
#include <tunables/global>

profile docker-default flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  # 允许网络操作
  network inet tcp,
  network inet udp,
  network inet icmp,

  # 限制 mount 操作
  deny mount fstype=ext3,
  deny mount fstype=ext4 -> /***,

  # 限制 sys_rawio
  deny capability sys_rawio,

  # 限制 ptrace
  deny ptrace (read, trace) peer=unconfined,

  # 允许指定文件读写
  /app/** rw,
  /var/log/app/** rw,

  # 拒绝访问敏感路径
  deny /etc/shadow r,
  deny /proc/sys/** w,
  deny /sys/** w,
}

Docker 默认运行在 AppArmor 的 docker-default profile 下，Kubernetes 则通过注解加载自定义 profile：container.apparmor.security.beta.kubernetes.io/<container>: runtime/default。

5. 镜像安全：签名、扫描与供应链防护

容器安全中，镜像供应链是最容易被攻破的环节。一个被污染的镜像从构建到部署可能影响数千个容器实例。

镜像签名与验证体系

• Docker Content Trust (DCT)： 基于 Notary v1 的签名方案，通过环境变量 DOCKER_CONTENT_TRUST=1 启用，对镜像 tag 进行签名
• Cosign (Sigstore)： CNCF 毕业项目，支持 keyless 签名模式（基于 OIDC 身份），是当前推荐方案
• Notation： Notary v2 的开源实现，支持 OCI 制品签名规范
• Kyverno/Gatekeeper 策略： 在准入控制层面验证镜像签名，拒绝未签名或签名无效的镜像

# Cosign keyless 签名（使用 GitHub OIDC 身份）
cosign sign --yes ghcr.io/myorg/myapp:latest

# 验证签名
cosign verify --certificate-identity-regexp="https://github.com/myorg/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:latest

# Kyverno 策略：要求镜像必须签名
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-signature
    match:
      any:
      - resources:
          kinds: [Pod]
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/myorg/myapp/.github/workflows/*@refs/tags/*"
            issuer: "https://token.actions.githubusercontent.com"
            rekorTransparencyLog:
              enabled: true

镜像漏洞扫描集成

常见的镜像扫描工具及其特点：

• Trivy： Aqua Security 开源，支持 OS 包漏洞、语言依赖、密钥泄漏、license 合规扫描
• Grype： Anchore 开源，数据库更新快速，支持 CVE 和 GHSA 数据源
• Snyk Container： 商业方案，与 CI/CD 深度集成，提供修复建议
• Clair： CoreOS 开源，被 Quay registry 采用，支持 webhook 通知

# Trivy 扫描最佳实践
# 扫描 OS 包 + 语言依赖 + 密钥
trivy image --scanners vuln,secret,config \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  --ignore-unfixed \
  ghcr.io/myorg/myapp:latest

# 生成 SARIF 报告集成 GitHub Security
trivy image --format sarif --output results.sarif myapp:latest

Distroless 镜像 — 最小化攻击面

Google 的 Distroless 镜像只包含应用及其运行时依赖，不包含 shell、包管理工具或系统工具。这种"空白容器"从根本上消除了容器内执行命令的可能性。

# 多阶段构建生成 Distroless 镜像
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.* ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /server ./cmd/server

FROM gcr.io/distroless/static-debian12:latest
COPY --from=builder /server /server
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/server"]

6. Kubernetes Pod Security Standards

Kubernetes 1.25+ 内置了三套 Pod Security Standards (PSS)，通过 Pod Security Admission (PSA) 控制器在 namespace 级别强制执行。

三级安全标准

• Privileged： 无限制，允许特权容器（仅用于系统组件）
• Baseline： 基本防护，禁止特权容器、hostNetwork、敏感 hostPath 挂载等
• Restricted： 严格限制，要求 runAsNonRoot、drop ALL capabilities、启用 Seccomp 和 SELinux

# Namespace 级别应用 Restricted 标准
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
---
# 部署到受保护 namespace 的 Pod 必须满足以下条件：
# 1. securityContext.runAsNonRoot = true
# 2. securityContext.allowPrivilegeEscalation = false
# 3. capabilities.drop = ["ALL"]
# 4. seccompProfile.type = "RuntimeDefault" 或 localhost
# 5. 不允许 hostPID/hostIPC/hostNetwork/hostPorts
# 6. 不允许敏感 hostPath 挂载（/etc, /var/run 等）

OPA/Gatekeeper 细粒度策略

PSP（Pod Security Policies）已废弃后，OPA Gatekeeper 提供了更灵活的策略引擎：

# Gatekeeper Constraint：禁止容器使用 latest tag
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowedTags
metadata:
  name: disallow-latest-tag
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
  - tags: ["latest"]
  - exemptImages: ["gcr.io/my-registry/trusted-app:latest"]

# Gatekeeper Constraint：限制 hostPath 挂载路径
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
  repos:
  - "gcr.io/my-registry/"
  - "docker.io/myorg/"

7. 网络安全：零信任网络策略

默认情况下，Kubernetes 集群内所有 Pod 可以自由通信，这与零信任架构的原则相悖。Network Policies 是容器网络隔离的核心机制。

默认拒绝所有流量

# 第一步：创建默认拒绝所有入站和出站流量的基线策略
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # 匹配所有 Pod
  policyTypes:
  - Ingress
  - Egress
---
# 第二步：按需开放特定通信
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    - namespaceSelector:
        matchLabels:
          name: monitoring  # 允许监控系统访问
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  - to:  # 允许 DNS 解析
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

服务网格的 mTLS 加密

在网络策略之上，服务网格（如 Istio、Cilium Service Mesh）提供应用层的零信任安全：

• 自动 mTLS： 服务间通信默认双向 TLS 加密，无需应用层改造
• AuthorizationPolicy： 基于服务身份的细粒度访问控制
• L7 策略： 可限制 HTTP 方法、路径、Header 等应用层语义
• 审计日志： 完整的请求级可观测性

8. 运行时威胁检测与响应

安全措施的最后一道防线是运行时检测。当攻击突破了隔离层时，及时检测和阻断异常行为至关重要。

Falco — 运行时安全监控

Falco（CNCF 毕业项目）通过内核模块或 eBPF 探针实时监控系统调用，基于规则引擎检测异常行为：

# falco 关键规则示例
- rule: Terminal shell in container
  desc: A shell was spawned inside a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, dash, ash)
  output: >
    Shell opened in container (user=%user.name
    container=%container.name shell=%proc.name)
  priority: NOTICE

- rule: Write to /proc/sys or /sys (kernel parameters)
  desc: Attempt to modify kernel runtime parameters
  condition: >
    open_write and container and
    fd.name startswith /proc/sys or
    fd.name startswith /sys
  output: >
    Kernel parameters modified from container
    (file=%fd.name user=%user.name container=%container.name)
  priority: WARNING

- rule: Outbound connection from sensitive container
  desc: Detect unexpected outbound connections
  condition: >
    outbound and container and
    not proc.name in (allowed_network_procs) and
    container.image.repository in (sensitive_images)
  output: >
    Unexpected outbound connection from sensitive container
    (connection=%fd.name container=%container.name)
  priority: CRITICAL

- rule: Mount宿主机敏感目录
  desc: Container mounts sensitive host filesystem
  condition: >
    spawned_process and container and
    proc.name = mount and
    (proc.args contains "/etc" or
     proc.args contains "/proc" or
     proc.args contains "/var/run/docker.sock")
  output: >
    Sensitive mount from container
    (mount=%proc.args container=%container.name)
  priority: EMERGENCY

Tetragon — eBPF 安全可观测性

Cilium Tetragon 是新一代的 eBPF 安全工具，相比 Falco 有独特优势：

• 在内核态进行策略判定： 不需要将事件拷贝到用户态，性能开销极低
• 进程全生命周期追踪： 可追踪进程 lineage（调用链），判断异常行为来源
• 文件完整性监控： 利用 eBPF 的 lsm hooks 在内核态执行文件访问策略
• 动态策略下发： 无需重启容器即可更新安全策略

9. 零信任架构下的容器安全战略

零信任（Zero Trust）的核心理念是"永不信任，始终验证"。在容器化环境中实施零信任需要以下关键组件：

身份与凭证管理

• 短期证书： 使用 SPIFFE/SPIRE 为每个工作负载分配唯一身份（SVID），证书有效期不超过数小时
• 密钥注入： 使用 External Secrets Operator 或 Vault Sidecar Injector，禁止在环境变量中硬编码密钥
• 凭证轮转： 数据库密码、API token 自动轮转，过期凭证立即失效
• Service Account Token： 使用 projected volume + Audience 限制 + 短暂过期时间

工作负载身份验证示例 (SPIFFE/SPIRE)

# SPIRE 为 pod 分配身份
# 基于 Service Account + Namespace 的节点选择器
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: backend-identity
spec:
  spiffeIDTemplate: "spiffe://{{ .TrustDomain }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}"
  podSelector:
    matchLabels:
      app: backend
  dnsNames:
  - "{{ .PodSpec.ServiceAccountName }}.{{ .PodMeta.Namespace }}.svc.cluster.local"

零信任容器安全架构全景

┌──────────────────────────────────────────────────────┐
│              零信任容器安全架构                        │
├──────────────────────────────────────────────────────┤
│  ┌─────────┐  ┌──────────┐  ┌────────────────────┐  │
│  │ SPIRE   │  │ Vault    │  │ Image Registry     │  │
│  │ 身份注入 │  │ 密钥管理 │  │ (签名验证+漏洞扫描) │  │
│  └────┬────┘  └────┬─────┘  └─────────┬──────────┘  │
│       │            │                  │              │
│  ┌────▼────────────▼──────────────────▼──────────┐  │
│  │         Admission Control Layer               │  │
│  │  Kyverno / Gatekeeper / Pod Security          │  │
│  └────────────────────┬──────────────────────────┘  │
│                       │                              │
│  ┌────────────────────▼──────────────────────────┐  │
│  │          Runtime Security Layer               │  │
│  │  Falco / Tetragon / Cilium Network Policy     │  │
│  └────────────────────┬──────────────────────────┘  │
│                       │                              │
│  ┌────────────────────▼──────────────────────────┐  │
│  │          System Hardening Layer               │  │
│  │  Seccomp + AppArmor/SELinux + Capabilities   │  │
│  │  User Namespace + Cgroup v2 + no-new-privs   │  │
│  └────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘

10. 生产级加固清单 (Security Hardening Checklist)

以下是一份可直接用于生产环境的容器安全加固清单，按优先级排列：

镜像构建阶段

• [ ] 使用多阶段构建，最终镜像不包含构建工具
• [ ] 使用 Distroless 或最小化基础镜像（Alpine/Scratch）
• [ ] 以非 root 用户运行应用（USER 1000）
• [ ] 删除不必要的 setuid/setgid 二进制文件
• [ ] 不安装 shell（sh/bash）和不必要的系统工具
• [ ] COPY 替代 ADD，避免远程 URL 和 tar 自动解压
• [ ] 扫描镜像漏洞，修复 HIGH/CRITICAL 级别 CVE
• [ ] 签名镜像并记录 SBOM (Software Bill of Materials)

部署配置阶段

• [ ] Pod Security Standards 设置为 restricted
• securityContext: runAsNonRoot=true, allowPrivilegeEscalation=false, readOnlyRootFilesystem=true
• capabilities.drop = ["ALL"]，仅添加必要 Capability
• seccompProfile.type = "RuntimeDefault"
• AppArmor/SELinux 启用默认或自定义 profile
• 配置 NetworkPolicy：默认拒绝所有，按需开放
• 敏感挂载使用 secret/configmap 而非 hostPath
• 设置合理的资源 limits（防止 DoS）
• 启用 audit logging，日志输出到集中式日志系统

运行时阶段

• 部署 Falco/Tetragon 进行运行时威胁检测
• 配置告警规则：shell 生成、敏感文件访问、异常网络连接
• 启用容器运行时审计（containerd/CRI-O auditd）
• 实施网络微隔离（Cilium Cluster Mesh）
• 定期扫描运行中的镜像（Trivy k8s 扫描模式）
• 密钥自动轮转（Vault/External Secrets Operator）
• 记录并监控容器镜像更新频率和变更来源

结语

容器安全不是一次性的配置动作，而是一个持续的、多层面的纵深防御体系。从内核隔离机制（Namespace/Cgroup）到权限精细管控（Capabilities/Seccomp），从强制访问控制（SELinux/AppArmor）到镜像签名与供应链防护，从网络安全策略（NetworkPolicy）到运行时威胁检测（Falco/Tetragon），每一层都在为上一层可能出现的失效提供后备保护。零信任架构将这些层次有机整合，通过身份认证、最小权限和持续验证构建了现代容器安全的完整框架。

在实际生产环境中，安全加固应该遵循"纵深防御 + 持续改进"的原则：先实施最关键的几项措施（非 root 运行、drop ALL capabilities、只读文件系统、NetworkPolicy 默认拒绝），再逐步完善检测和响应能力。记住，安全的目标不是消除所有风险，而是将风险降低到可接受的范围内，并在被突破时能够快速发现和遏制。