本文目录导读：
集群安全策略配置是一个系统性工程,需要覆盖从基础设施到应用层、从网络边界到数据存储的多个维度，不同集群类型（如Kubernetes、Hadoop、Elasticsearch）的侧重点不同，但核心原则和通用策略是相通的。
下面以最主流的Kubernetes (K8s)容器编排集群为例，说明如何系统性地配置安全策略，这些思路也适用于大多数分布式集群。
核心原则：纵深防御与最小权限
在配置任何策略前,先确立两个核心原则：
- 纵深防御：不依赖单一安全机制，网络层、节点层、容器层、API层、数据层都应有防护。
- 最小权限：任何实体（用户、Pod、服务）只拥有完成其任务所需的最小权限。
集群安全策略配置的四大维度
基础设施与节点安全
这是集群的底座,如果节点被攻破，上层所有策略都可能失效。
- 操作系统加固：
- 定期更新节点OS内核和系统包,修复已知漏洞。
- 禁用不必要的服务和端口（如SSH仅允许特定IP或使用堡垒机）。
- 配置主机入侵检测系统。
- 节点访问控制：
- 禁止直接SSH登录节点，必须通过堡垒机或K8s API进行操作。
- 为节点配置独立的、具有最小权限的Service Account（用于与云平台API交互）。
- etcd 加密与认证：
- etcd是集群的大脑,必须启用TLS双向认证（mTLS）。
- 对etcd中的Secret数据启用静态加密（Encryption at Rest）。
- 网络平面隔离：
- 将集群网络、节点网络、存储网络分离于不同的VLAN或子网。
- 使用安全组/防火墙规则，仅允许集群内部和必要的管理流量。
集群 API 与认证授权
这是集群的“大门”，必须严格控制谁能进来以及能做什么。
- API Server 加固：
- 启用 HTTPS (TLS 1.2+) 并配置强加密套件。
- 禁用匿名请求 (
--anonymous-auth=false)。 - 启用审计日志 (
--audit-log-path)，记录所有API请求，尤其关注写操作和敏感资源访问。
- 认证机制（Authentication）：
- 不使用共享Token或证书，推荐使用OIDC（如集成企业LDAP、GitHub SSO）或云服务商的IAM集成。
- 为不同角色创建独立的服务账号（Service Account），不为“默认”服务账号授予权限。
- 授权模型（Authorization）：
- 必须使用RBAC，禁用更宽泛的ABAC。
- 实施最小权限原则：
- Namespce 级别权限：开发人员通常只需其项目的
Namespace内权限。 - Cluster 级别权限：仅授予集群管理员。
- Namespce 级别权限：开发人员通常只需其项目的
- 使用角色聚合：通过
ClusterRole的aggregationRule简化权限管理。 - 关闭
automountServiceAccountToken：对于不需要与API交互的Pod，在其PodSpec中设置automountServiceAccountToken: false。
工作负载与容器运行时安全
这是Pod运行的地方,也是攻击面最大的区域。
- Pod 安全标准（Pod Security Standards，PSS）：这是最重要的策略之一。
- 对每个命名空间实施Pod Security Admission (PSA) 控制策略，以前叫PSP。
- 分层策略：
- Privileged：仅用于系统组件（如Ingress Controller、CNI插件）。不用于业务。
- Baseline：适用于大多数业务Pods（阻止了已知的特权升级）。
- Restricted：最高安全等级（强制的，如禁止
privileged: true、禁止hostNetwork、runAsNonRoot: true等）。
- 实践：为
production命名空间设置Restricted级别，为staging设置Baseline级别。
- 容器镜像安全：
- 使用可信的镜像源：内部私有镜像仓库（Harbor, Nexus）。
- 镜像签名验证：只运行经过签名的镜像。
- 镜像漏洞扫描：在CI/CD流程中和仓库中集成扫描工具(Trivy, Clair, Anchore)。
- 不使用
latest：使用固定的版本标签。
- 安全上下文（Security Context）：在每个Pod或容器定义中必须配置。
runAsNonRoot: true：禁止容器以root用户运行。 （最基础的策略）runAsUser: [非rootUID]：明确指定容器用户ID。capabilities.drop: ["ALL"]：丢弃所有Linux Capability，然后按需添加（如NET_BIND_SERVICE）。readOnlyRootFilesystem: true：让根文件系统只读，应用需要写数据时必须挂载emptyDir或持久卷。
- 网络策略（Network Policies）：
- 默认拒绝所有入口和出口流量。
- 显式定义允许的流量。
- Web前端Pod允许被Ingress访问。
- API后端Pod仅允许被Web前端Pod访问,并允许连接数据库。
- 数据库Pod仅允许被API后端Pod访问,并拒绝所有出站流量。
数据与服务安全
- 密钥管理：
- 绝不将敏感信息硬编码在镜像或配置文件中。
- 使用K8s Secret 对象，并确保开启etcd静态加密。
- 集成外部密钥管理服务（HashiCorp Vault, AWS Secrets Manager）实现动态密钥和审计。
- 传输加密：
- 如果集群内服务间通信需要加密（尤其是处理敏感数据的服务），应启用Service Mesh（如Istio, Linkerd）的mTLS功能，实现自动、透明的加密。
- 数据持久化安全：
- 为存储卷启用加密（存储层加密或文件系统加密）。
- 设置恰当的存储卷访问模式（如
ReadWriteOnce而非ReadWriteMany）。 - 实施备份和恢复策略。
策略配置实施流程
不要一次性全部配置,建议按以下步骤迭代：
- 审计与基线建立：
- 使用
kube-bench检查CIS Kubernetes Benchmark。 - 使用
kubectl audit开启审计日志并分析。 - 使用
kube-hunter扫描已知漏洞。
- 使用
- 制定安全策略：
- 根据业务风险等级,为不同命名空间定义不同的PSS策略（如上文Restricted/Baseline/Privileged）。
- 编写初始的网络策略（先开始一个命名空间作为试点）。
- 策略实施：
- 建议先使用
Warn或Audit模式部署策略（如PSA），这样不会立即拒绝，而是记录违反策略的Pod，观察一段时间，确定没有问题。 - 逐步将策略从
Warn切换到Enforce模式。
- 建议先使用
- 自动化与持续监控：
- 在CI/CD流水线中集成安全扫描（Trivy, SonarQube, 镜像签名验证）。
- 使用策略即代码工具（如Open Policy Agent Gatekeeper, Kyverno）来定义、分发自定义安全策略。
- 将审计日志导入SIEM系统,设置告警（如“创建特权容器”、“访问Secret”告警）。
- 定期评审与更新：
安全是动态过程,定期（如每季度）评审安全策略，更新组件版本，应对新的CVE。
一份快速检查清单
在配置集群安全策略时,可以对照以下清单：
- [必须] 开启etcd加密？
- [必须] 开启RBAC并严格配置角色？
- [必须] 所有Pod都配置了
runAsNonRoot: true？ - [必须] 所有Pod都丢弃了所有Capabilities？
- [必须] 命名空间实施了Pod Security Admission（至少Baseline）？
- [强烈建议] 实施默认拒绝的Network Policy？
- [强烈建议] 使用私有镜像仓库并开启扫描？
- [强烈建议] Secret集成外部密钥管理服务？
- [最佳实践] 开启审计日志并监控告警？
- [最佳实践] 使用策略引擎（Gatekeeper/Kyverno）执行自定义规则？
通过以上系统化的策略配置,可以将集群的整体安全水位提升到一个相当高的水平，如果有具体的集群类型（如Hadoop、Elasticsearch）或具体场景（如金融、医疗），可以进一步提供针对性的建议。
