Kubernetes 安全基础：构建强大的防御

发布: 4天前 (2026年1月4日 GMT+8 16:57)

10 min read

I’m happy to help translate the article, but I need the full text you’d like translated. Could you please provide the content (excluding the source line you already shared) so I can translate it into Simplified Chinese while preserving the formatting and code blocks?

Kubernetes 攻击面

在深入具体的安全措施之前，了解构成 Kubernetes 攻击面的各种组件至关重要。

组件	描述
控制平面	集群的大脑（API Server、etcd、Controller Manager、Scheduler）。一旦被攻破，攻击者即可对整个集群获得显著控制权。
工作节点	运行应用容器的机器。操作系统、容器运行时或 kubelet 中的漏洞可能被利用，以获取节点访问权限，进而威胁整个集群。
容器	虽然容器提供进程隔离，但容器镜像本身的错误配置或漏洞也会导致安全问题。
网络	Pod、服务以及外部实体之间的通信通道是主要的攻击向量。不安全的网络配置可能导致未授权访问或数据泄漏。
数据	存储在持久卷或 Secrets 中的敏感数据需要强有力的保护，以防止未授权访问。
用户与服务账户	对人类用户和 Kubernetes 服务账户的访问控制不足可能导致特权提升。

核心安全原则

一个全面的 Kubernetes 安全策略建立在若干核心原则之上：

1. 最小特权

仅授予实体（用户、服务账户、进程）执行其预期功能所需的最小权限。

示例： 与其给 Deployment 赋予完整的 cluster-admin 权限，不如定义一个 Role 或 ClusterRole，专门允许它在其命名空间内管理 Deployments、Pods 和 Services。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: deployment-manager
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

将此 Role 绑定到你的应用使用的 ServiceAccount。

2. 深度防御

实施多层安全控制。若某一层失效，其他层仍能防止完整的妥协。

示例：

网络策略（Network Policies）限制 pod 与 pod 之间的通信。
准入控制器（Admission Controllers）强制执行安全最佳实践。
强大的 RBAC 实现细粒度访问控制。

3. 不可变基础设施

将基础设施视为可随时替换的资源。不要在现有节点/容器上打补丁或修改，而是用新的、安全的版本替换它们。这可以减少配置漂移和持久性漏洞。

示例： 当在基础容器镜像中发现漏洞时，构建一个已应用补丁的新镜像，然后使用更新后的镜像重新部署应用。避免通过 SSH 进入运行中的容器进行修复。

4. 持续监控与审计

定期监控集群的可疑活动、错误配置和安全事件。实施全面审计，以追踪 谁在何时何地做了什么。

示例：

启用 Kubernetes 审计日志，捕获 API 请求。
使用 kube-audit、Falco 等工具，或将日志集成到 SIEM（安全信息与事件管理）系统中，以检测异常。

基本安全控制

1. API 服务器

API 服务器是集群的中心网关。

Authentication – 强制使用强身份验证机制（TLS 客户端证书、OIDC、服务账户令牌）。
Authorization (RBAC) – 定义细粒度的 Roles/ClusterRoles，并通过 RoleBindings/ClusterRoleBindings 进行绑定。

2. 网络策略

网络策略对集群进行分段并控制流量走向。

默认情况下，所有 Pod 可以自由通信。网络策略会改变这一点。

示例： 允许前端 Pod 在端口 80 与后端 Pod 通信，同时拒绝所有其他进入后端的流量。

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

3. 服务网格（可选）

考虑使用 Istio 或 Linkerd 等服务网格，以获得高级网络安全功能：

互相 TLS（mTLS）用于加密 Pod 与 Pod 之间的通信。
细粒度流量控制。
增强的可观测性。

4. 容器镜像安全

容器镜像的安全是基础。

Image Scanning – 在部署前扫描镜像中的已知漏洞（CVE）；将扫描集成到 CI/CD 流水线中。
Minimal Base Images – 使用轻量、可信的基础镜像（例如 alpine），以降低攻击面。
Don’t Run as Root – 配置容器以非 root 用户运行。

Dockerfile 示例：

# Use a minimal base image
FROM alpine:3.18

# Add a non‑root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Switch to the non‑root user
USER appuser

# ... rest of the Dockerfile ...

结束语

确保 Kubernetes 的安全是一个持续的过程，需要流程、技术和人员的协同配合。通过了解攻击面、运用核心安全原则，并实施具体的控制措施——如 RBAC、网络策略、不可变基础设施以及持续监控——您可以构建一个有弹性的防御体系，保护工作负载、数据和声誉。

保持警惕，及时更新工具链，并将集群的每个组件视为必须加固的潜在入口点。

文档结束

FROM alpine:latest
# ... other instructions
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
# ... rest of your Dockerfile

保护 Pod 本身

Pod 安全标准 (PSS) / Pod 安全准入 (PSA)

Kubernetes 提供内置机制，在 Pod 级别强制执行安全最佳实践。PSA 在 命名空间 级别实施 PSS，防止 Pod 以过高的特权运行。

安全上下文

在 Pod 或容器规范中配置 securityContext，以控制特权提升，设置 Seccomp 配置文件、AppArmor 配置文件和 SELinux 上下文。

示例 – 为容器禁用特权提升

apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
spec:
  containers:
  - name: my-container
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false

保护敏感信息（API 密钥、密码、证书）

Kubernetes Secrets – 将敏感数据存储在 Secret 对象中。
Encryption at Rest – 配置 etcd 对敏感数据进行静态加密。
External Secrets Managers – 与 HashiCorp Vault、AWS Secrets Manager、Azure Key Vault 等集成，实现集中管理和增强安全性。

确保底层基础设施的安全

Regular Patching – 确保工作节点上的操作系统和容器运行时保持最新的安全补丁。
Secure Configuration – 加固节点配置；禁用不必要的服务和端口。
Runtime Security – 部署运行时安全工具（例如 Falco、Sysdig Secure），以检测并警报容器内及节点上的可疑活动。

准入控制器

准入控制器在 身份验证和授权之后、对象持久化之前 拦截对 Kubernetes API 服务器的请求。它们可以强制执行安全策略。

内置准入控制器 – 例如 PodSecurity（用于 PSA）、NamespaceLifecycle、LimitRanger。
动态准入控制器 – 使用 webhook 实现高级策略强制。诸如 OPA Gatekeeper 或 Kyverno 等工具能够实现细粒度的策略定义和执行。

示例 – OPA Gatekeeper 策略，确保所有容器镜像均来自受信任的仓库

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: trusted-registry
spec:
  enforcementAction: deny
  parameters:
    repos:
    - "mytrustedregistry.com"

综合日志记录与审计

审计日志 – 为 Kubernetes API 服务器启用详细审计日志记录。
容器日志 – 确保应用程序生成有用的日志并被收集。
集中式日志 – 将所有集群组件和应用程序的日志转发到集中系统（例如 Elasticsearch、Loki、Splunk），用于分析和告警。

最后思考

确保 Kubernetes 集群的安全是一个持续的过程，而不是一次性任务。通过：

了解攻击面，
应用最小权限和深度防御原则，
为 API 服务器、网络、镜像、Pod、密钥和节点实施强有力的控制，
利用准入控制器，以及
保持全面的日志记录和持续监控，

您可以显著提升 Kubernetes 的安全姿态。定期的安全评估、持续的警惕以及跟进最佳实践，是构建安全且具韧性的 Kubernetes 环境的关键。