Kubernetes 安全最佳实践 | Decripte Security

Kubernetes 彻底改变了大规模容器的编排与管理，已成为部署云原生应用的 事实标准，但与传统部署模型相比，其分布式架构和 固有的复杂性引入了显著扩大的攻击面。 一个典型的 Kubernetes 集群涉及数十个相互关联的组件 —— API server、etcd、scheduler、controller manager、kubelet、kube-proxy —— 每个组件都有 其自身潜在的漏洞和特定的加固要求。K8s 的动态特性， 即 pods 不断被创建和销毁、workloads 在 nodes 之间迁移，以及网络策略 必须实时应用，使得安全成为一项需要纵深防御方法的 多维挑战。不安全的默认配置，例如 RBAC 中过于 宽松的权限、缺少允许 pods 之间无限制通信的 network policies、 以 root 身份运行且具有特权 capabilities 的容器，以及以明文存储在 未加密 etcd 中的 secrets，都是在配置不当的 K8s 环境中 常被利用的攻击向量。本文探讨 Kubernetes 集群加固的基本实践，涵盖 基于角色的访问控制（RBAC）、pod security standards、用于微分段的 network policies、 安全的密钥管理、用于策略实施的 admission controllers、 使用 Falco 等工具进行的运行时安全监控，以及对行业基准（如 CIS Kubernetes Benchmark）的合规性，为在生产环境中构建和运营 安全的 Kubernetes 集群提供一份完整的路线图。

K8s 安全架构

Kubernetes 集群包含多个关键组件：

• Control Plane： API Server、etcd、scheduler、controller manager
• Nodes： kubelet、kube-proxy、container runtime
• Add-ons： DNS、dashboard、ingress controllers

RBAC（Role-Based Access Control）

RBAC 是 K8s 安全的基础，通过 API server 控制谁可以访问什么。

RBAC 配置

      # 用于读取特定 namespace 中 pods 的 Role
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: production
      name: pod-reader
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
      ---
      # RoleBinding 将 role 关联到用户
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
      name: read-pods
      namespace: production
      subjects:
      - kind: User
      name: jane
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io
      

RBAC 原则

• Least privilege： 仅授予必要的权限
• 避免 ClusterAdmin： 按职能创建特定的 roles
• Service accounts： 每个 pod 都应有专用的 SA
• Namespace isolation： 使用 RoleBindings 而非 ClusterRoleBindings

Pod Security

Pod Security Standards

Kubernetes 1.25+ 使用 Pod Security Admission 取代已弃用的 PSPs：

• Privileged： 无限制，适用于受信任的 workloads
• Baseline： 最低限度的限制，防止已知的提权
• Restricted： 高度限制，遵循加固最佳实践

Security Context

      apiVersion: v1
      kind: Pod
      metadata:
      name: secure-pod
      spec:
      securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      fsGroup: 2000
      seccompProfile:
      type: RuntimeDefault
      containers:
      - name: app
      image: myapp:latest
      securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
      drop:
      - ALL
      

Network Policies

默认情况下，pods 可以自由通信。Network Policies 实现分段：

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: api-allow-from-frontend
      namespace: production
      spec:
      podSelector:
      matchLabels:
      app: api
      policyTypes:
      - Ingress
      ingress:
      - from:
      - podSelector:
      matchLabels:
      app: frontend
      ports:
      - protocol: TCP
      port: 8080
      

密钥管理

• 切勿硬编码 secrets： 使用 Kubernetes Secrets 或外部 vaults
• etcd encryption： 为 etcd 启用 encryption-at-rest
• External Secrets Operator： 与 Vault、AWS Secrets Manager 集成
• 轮换 secrets： 实施自动轮换
• secrets 的 RBAC： 限制谁可以读取 secrets

Image Security

• Private registries： 生产环境中不要使用公共 registries
• Image scanning： 使用 Trivy、Clair、Anchore 进行漏洞扫描
• Image signing： 使用 Cosign 验证完整性
• Admission controllers： 在部署前验证 images
• Distroless images： 最小化攻击面

Admission Controllers

API Server 加固

• 启用 audit logging
• 对所有通信使用 TLS
• 禁用 anonymous auth
• 实施 API rate limiting
• 限制对 API server 的访问（network ACLs）

Runtime Security

• Falco： 面向 K8s 的运行时威胁检测
• Sysdig Secure： 运行时保护与合规
• Aqua Security： 全生命周期容器安全

合规与审计

• CIS Kubernetes Benchmark： 加固框架
• kube-bench： 自动化 CIS 合规检查
• kube-hunter： 面向 K8s 的渗透测试工具
• Audit logs： 集中到 SIEM 进行分析

Service Mesh Security

Service meshes（Istio、Linkerd）增加了一层安全：

• pods 之间自动 mTLS
• 细粒度的授权策略
• 传输中流量加密
• Observability 与 auditability