容器安全最佳实践：保护 Docker 和 Kubernetes 环境

容器安全最佳实践：保护 Docker 和 Kubernetes 环境

容器和 Kubernetes 已成为现代应用部署的事实标准，但容器化带来的安全挑战与传统虚拟机环境截然不同。共享内核、不可变镜像、动态 IP 和声明式配置等特点，要求安全团队采用全新的思维方式。根据 CNCF 2026 年度安全调查，68% 的受访企业在过去 12 个月内经历过至少一次容器安全问题。本文从镜像安全、运行时防护、Kubernetes 配置加固、网络安全、合规审计五个层面，提供一套完整的容器安全实施指南。

镜像安全：构建阶段的防线

基础镜像的选择与管理

Docker 镜像的安全漏洞中，超过 60% 来源于基础镜像中的已知漏洞。选择合适的基础镜像是安全的第一道关口：

推荐策略：将基础镜像的选用纳入企业安全策略。

# ❌ 不推荐的方案：使用最新的 Ubuntu
FROM ubuntu:latest

# ✅ 推荐的方案：使用 Distroless 指定版本
FROM gcr.io/distroless/static-debian12:nonroot

COPY --from=builder /app/server /app/server
USER nonroot:nonroot
ENTRYPOINT ["/app/server"]

镜像扫描自动化

在 CI/CD 管道中集成镜像扫描是最有效的漏洞拦截手段：

# GitHub Actions + Trivy 镜像扫描
name: Container Security Scan
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t app:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'app:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'  # 发现高危漏洞即终止构建

      - name: Upload scan results to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

镜像签名与验证

使用 Docker Content Trust（DCT）或 Cosign 对镜像进行签名，确保镜像在构建后未被篡改：

# 使用 Cosign 签名和验证
# 生成密钥对
cosign generate-key-pair

# 签名镜像
cosign sign --key cosign.key ghcr.io/myorg/myapp:v1.2.3

# 部署前验证签名
cosign verify --key cosign.pub ghcr.io/myorg/myapp:v1.2.3

运行时安全

容器资源限制

适当限制容器的资源使用可以防止 DoS 攻击和资源耗尽问题：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: myapp:1.0.0
    resources:
      requests:
        memory: "256Mi"
        cpu: "0.5"
      limits:
        memory: "512Mi"
        cpu: "1.0"
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 10001
      runAsGroup: 10001
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true

运行时安全监控

Falco 规则示例：检测容器内的反弹 shell

# falco_rules.yaml
- rule: Detect Reverse Shell
  desc: 检测容器内启动反向 shell 的行为
  condition: >
    spawned_process and
    container and
    (proc.name in ("bash", "sh", "zsh") and
     proc.args contains "/dev/tcp/")
  output: >
    Reverse shell detected in container
    (user=%user.name container=%container.name
     image=%container.image proc=%proc.name cmdline=%proc.cmdline)
  priority: CRITICAL
  tags: [shell, network, mitre_execution]

Kubernetes 配置加固

RBAC 最小权限原则

Kubernetes RBAC 是访问控制的核心。以下是一个遵循最小权限原则的配置示例：

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "endpoints"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: app-role-binding
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: production
roleRef:
  kind: Role
  name: app-role
  apiGroup: rbac.authorization.k8s.io

Pod 安全标准（PSA）

Kubernetes v1.25+ 内置了 Pod Security Admission，替代了早期的 PSP（Pod Security Policy）：

# 在命名空间级别强制安全标准
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

网络安全策略

Kubernetes 网络策略

默认情况下，Kubernetes 允许所有 Pod 间通信（"全通"模型）。通过网络策略（NetworkPolicy）实现微隔离：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
  - Ingress
  - Egress
  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:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

服务网格安全

服务网格（Istio、Linkerd、Cilium）为容器环境提供了更强大的安全能力：

# Istio 授权策略示例：仅允许符合 JWT 声明的请求
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-authz
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["*"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/payments"]
    when:
    - key: request.auth.claims[role]
      values: ["admin", "finance"]

合规与审计

Kubernetes 合规扫描

使用工具自动检查集群配置是否符合行业合规标准：

# kube-bench: 检查 CIS Kubernetes Benchmark
kube-bench run --targets master,node --version 1.30

# 检查结果示例
# [PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive
# [FAIL] 1.2.6 Ensure that the --kubelet-certificate-authority flag is set as appropriate
# [WARN] 1.2.22 Ensure that the --service-account-lookup flag is set to true

审计日志

# kube-apiserver 审计策略配置
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps", "pods/exec"]
- level: Metadata
  resources:
  - group: rbac.authorization.k8s.io
  - group: ""
    resources: ["namespaces", "nodes", "serviceaccounts"]
- level: None
  resources:
  - group: ""
    resources: ["events"]
  - group: coordination.k8s.io
  - verbs: ["get", "list", "watch"]

安全工具链全景

容器安全工具链推荐配置：

┌─────────────────────────────────────────────┐
│              开发阶段                        │
│  Trivy / Snyk → 镜像漏洞扫描                 │
│  Dockle → Dockerfile 最佳实践检查             │
│  Cosign → 镜像签名                           │
├─────────────────────────────────────────────┤
│              构建 & CI/CD                    │
│  Trivy → CI 集成阻断                         │
│  OPA Gatekeeper / Kyverno → 策略即代码       │
│  Docker Scout → 镜像元数据追踪               │
├─────────────────────────────────────────────┤
│              部署阶段                        │
│  kube-bench → 集群安全基线检查                │
│  kube-hunter → 渗透测试                      │
│  Polaris → Kubernetes 配置安全检查            │
├─────────────────────────────────────────────┤
│              运行时                          │
│  Falco → 运行时异常检测                      │
│  Cilium → eBPF 驱动的网络与安全              │
│  Istio → 服务网格 mTLS + 授权               │
│  OPA/Gatekeeper → 准入控制                   │
└─────────────────────────────────────────────┘

总结与实践路线图

实施容器安全不是一蹴而就的。建议按照以下优先级逐步推进：

核心原则：容器安全不是单一工具能解决的，而是需要贯穿构建、部署和运行的 DevOps 流程。安全左移（Shift Left）——在开发阶段就发现并修复安全问题——永远比在运行时补救更高效、成本更低。