Kubernetes安全怎么配置？

wen 网络安全 2026-07-21 4

Kubernetes安全怎么配置？——从入门到生产级防护的完整指南

目录导读

Kubernetes安全的重要性与挑战
基础安全配置：从集群安装开始
RBAC权限控制与最小权限原则
网络策略与Pod安全上下文
Secrets管理与敏感信息保护
镜像安全与供应链防护
审计日志与运行时安全监控
常见安全问题问答

Kubernetes安全的重要性与挑战

Kubernetes（简称K8s）已成为容器编排的事实标准，但其复杂的组件和动态的环境也带来了诸多安全隐患，根据云原生计算基金会（CNCF）的报告，超过60%的K8s集群在生产环境中存在至少一个严重安全风险，常见的威胁包括：未授权访问、容器逃逸、敏感信息泄露、供应链攻击等。

Kubernetes安全怎么配置？

Q：为什么K8s安全比传统虚拟机更复杂？
A：K8s增加了控制平面、etcd、API Server、Kubelet等多个攻击面，且Pod是短暂的、动态调度的，传统安全边界（如防火墙）难以有效覆盖，镜像层、网络策略、RBAC等都需要精细配置。

基础安全配置：从集群安装开始

在部署集群时,就需要建立安全基线：

证书与加密：所有组件间通信必须使用TLS，确保kubelet、API Server、etcd之间的证书由可信CA签发，建议使用kubeadm自动生成的证书，或使用cert-manager管理。
控制平面隔离：将控制平面节点标记为不可调度（kubectl taint），避免业务Pod运行在Master节点上，减少攻击面。
版本更新：始终使用K8s的最新稳定版本，每个版本都修复了大量CVE，例如CVE-2023-3676（Kubelet权限提升）在1.28.4中已修复。

Q：如何验证集群的TLS配置是否安全？
A：可以使用kube-bench工具（基于CIS Benchmark）扫描集群，运行kube-bench master和kube-bench node检查证书、API Server匿名访问等配置。

RBAC权限控制与最小权限原则

RBAC（基于角色的访问控制）是K8s安全的核心，配置时务必遵循以下原则：

禁用匿名访问：在API Server启动参数中设置--anonymous-auth=false，默认情况下，匿名用户有部分访问权限。
创建精细化角色：不要使用cluster-admin角色给普通用户或服务账户，为CI/CD流水线创建只能操作特定命名空间的Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

定期审计：使用kubectl auth can-i --list或工具rbac-tool检查当前绑定的权限，发现大量通配符权限时需立即整改。

Q：服务账户（ServiceAccount）默认权限是安全的吗？
A：并非如此，默认的ServiceAccount绑定到default命名空间且没有显式权限，但某些K8s版本会授予system:authenticated组的权限，建议为每个Pod创建专用的ServiceAccount，并显式绑定最小权限的Role。

网络策略与Pod安全上下文

1 网络策略（NetworkPolicy）

默认情况下,所有Pod可以互相通信，必须使用网络策略限制流量：

配置默认拒绝：在命名空间内创建只允许特定入站/出站的策略。
只允许前端访问后端：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

工具选择：Calico、Cilium、Weave Net等CNI插件都支持网络策略，生产环境推荐Calico，支持细粒度IP段控制。

2 Pod安全上下文（SecurityContext）

配置Pod或容器的安全上下文,防止容器逃逸：

禁止特权模式：privileged: false
禁止以root运行：runAsNonRoot: true
使用只读根文件系统：readOnlyRootFilesystem: true
移除Linux能力：设置capabilities: drop: ["ALL"]

Q：如果必须使用特权容器（如监控Agent），如何最小化风险？
A：使用Pod安全准入（PSA或OPA Gatekeeper），对于特权容器，添加以下限制：

使用ContainerRuntime为“runc”或“gVisor”

启用SELinux或AppArmor配置文件

限制其为hostNetwork: false，避免直接操作宿主机网络。

Secrets管理与敏感信息保护

K8s原生的Secret对象默认只是Base64编码,并非加密，安全配置要点：

启用加密：在API Server中开启--encryption-provider-config，使用AES-GCM或KMS（推荐KMS，如AWS KMS、GCP Cloud KMS），示例：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: c2VjcmV0LWxvbmcta2V5LXRlc3Q=
  - identity: {}

禁用环境变量注入：在Pod中通过挂载卷的方式读取Secret，而不是用envFrom，因为环境变量可能被/proc或日志泄露。
使用外部Secrets管理器：集成Hashicorp Vault、AWS Secrets Manager等，通过CSI Driver（如secrets-store-csi-driver）动态注入，避免Secret在etcd中存储。

Q：如何排查Pod是否泄露了Secret？
A：使用工具kubescape或trivy扫描集群，检查是否有Secret被打印到日志、或以环境变量形式暴露，还可以通过审计日志检测get secrets动作的异常频次。

镜像安全与供应链防护

镜像供应链攻击（如2023年流行的“shadow attack”）是主要威胁之一，必须做到：

仅使用可信镜像仓库：配置ImagePolicyWebhook或OPA Gatekeeper，禁止从Docker Hub的公开仓库拉取未经签名的镜像。
镜像扫描：在CI/CD阶段集成trivy、clair或snyk扫描镜像漏洞，对于基础镜像，选择官方维护的alpine、distroless（最小化攻击面）。
强制镜像签名：使用cosign签名镜像，并配置K8s准入控制器验证签名，所有镜像必须由指定密钥签名才能运行。

Q：如果镜像漏洞得分很高但业务无法立即更新，如何应对？
A：对运行中的Pod应用安全上下文限制（如设置seccompProfile: RuntimeDefault），并部署运行时安全监控工具如Falco或Sysdig，检测容器内的异常行为（如执行/bin/sh、写入/etc）。

审计日志与运行时安全监控

启用审计日志：配置API Server的--audit-policy-file，定义需要记录的事件（如创建Pod、删除Service），审计日志应发送到集中式日志系统（如Elasticsearch、Splunk）进行异常检测。
运行时安全：使用Falco（CNCF毕业项目）监控系统调用，示例告警规则：
rule: 容器内执行shell desc: detect shell execution in container condition: container.id != "" and proc.name in (bash, sh, zsh) and evt.type = execve output: "Shell executed in container (user=%user.name container=%container.id shell=%proc.name)" priority: WARNING
网络流量监控：在Cilium或Calico中启用“网络审计模式”，记录所有被拒绝的流量。

Q：如何区分正常运维操作与攻击行为？
A：建立基线模型，使用KubeClarity或KubeHound分析容器之间的通信模式，一旦发现不符合基线的行为（如Pod突然访问外网IP），立即触发自动隔离。

常见安全问题问答

问题	解决方案
Q：K8s Dashboard是否安全？	建议禁用Dashboard，改用kubectl + oauth2-proxy，如果必须使用，开启身份认证且绑定最小权限角色，并对外暴露时启用HTTPS和IP白名单。
Q：如何保护etcd？	etcd默认监听在localhost，但若暴露到外网则非常危险，确保：① 防火墙仅允许控制平面节点访问；② 开启TLS客户端证书认证；③ 定期备份并加密存储。
Q：Pod之间需要隔离吗？	是，除了网络策略，还可以使用“Pod安全准入”（PSA）或“Kata Containers”实现虚拟化级别的隔离，对于多租户环境，推荐使用命名空间+资源配额+网络策略+Pod安全上下文的组合方案。
Q：为什么CVE-2023-44487影响K8s？	该CVE是HTTP/2的Rapid Reset攻击，影响所有使用HTTP/2的组件，包括API Server和Kubelet，解决方法是升级K8s到1.27.8+/1.28.4+版本，或禁用HTTP/2协议。

Kubernetes安全不是单一配置能解决的,需要从集群搭建、权限控制、网络隔离、镜像管理、运行时监控等多个维度构建纵深防御，建议定期使用kube-bench、kubescape进行合规扫描，并结合SIEM系统实现自动告警，记住：最小权限、默认拒绝、持续审计是K8s安全的三大基石。