3. K8s配置对象概览:Pod、Deployment、Service、ConfigMap、Secret、RBAC、NetworkPolicy等关键资源的配置要点
在 Kubernetes 集群中,一切皆对象。合规核验的第一步,是准确理解每个核心配置对象的结构、字段含义与安全基线。本章将逐一拆解 Pod、Deployment、Service、ConfigMap、Secret、RBAC、NetworkPolicy 七类关键资源,聚焦于合规性检查点与环境一致性要求。
核验原则:每个对象的配置清单应同时满足“最小权限”、“显式声明”、“版本锁定”三项基线。任何隐式默认值或缺失字段,都应视为潜在合规风险。
3.1 Pod —— 原子调度单元的安全基线
Pod 是 Kubernetes 中最小的部署单元,合规核验需关注以下字段:
| 配置字段 | 合规要点 | 常见违规 |
|---|---|---|
securityContext.runAsNonRoot |
必须为 true,禁止以 root 运行 |
缺失或设为 false |
securityContext.capabilities.drop |
至少 drop ALL,再按需添加 |
未显式 drop 任何 capability |
resources.requests/limits |
必须设置 CPU/Memory 的 requests 和 limits | 仅设 requests 或完全缺失 |
imagePullPolicy |
生产环境建议 Always 或 IfNotPresent |
使用 Never 或未指定 |
hostNetwork / hostPID / hostIPC |
默认禁止,除非显式审批 | 误设为 true |
# 合规 Pod 示例片段
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1001
fsGroup: 2000
containers:
- name: app
image: myapp:1.0.0
imagePullPolicy: IfNotPresent
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
securityContext:
capabilities:
drop: ["ALL"]
readOnlyRootFilesystem: true
3.2 Deployment —— 声明式更新与副本合规
Deployment 是工作负载管理的主要对象,合规核验重点在于更新策略与副本一致性:
- strategy.type:生产环境建议
RollingUpdate,避免Recreate导致服务中断。 - revisionHistoryLimit:建议保留 3~5 个历史版本,便于回滚审计。
- minReadySeconds:至少 30s,确保新 Pod 稳定后再切换流量。
- progressDeadlineSeconds:设置 600s 超时,避免滚动更新卡死。
- pod template 标签:必须与 Service 的 selector 精确匹配,否则流量丢失。
环境一致性检查:不同环境(dev/staging/prod)的 Deployment 应使用相同的
replicas 基数 + 环境特定覆盖,而非硬编码不同副本数。推荐使用 Kustomize 或 Helm values 管理差异。
3.3 Service —— 网络端点与暴露控制
Service 定义了 Pod 的访问方式,合规核验聚焦于暴露范围与端口命名:
| Service Type | 合规建议 | 风险场景 |
|---|---|---|
| ClusterIP | 内部服务默认类型,无需额外暴露 | 误设为 NodePort 或 LoadBalancer |
| NodePort | 仅用于开发调试,生产需审批 | 端口范围未限制(默认 30000-32767) |
| LoadBalancer | 必须绑定安全组/防火墙规则 | 直接暴露到公网无 ACL |
| ExternalName | 谨慎使用,避免 DNS 劫持 | 指向外部不可信域名 |
端口命名规范:每个端口必须包含 name 字段,格式为 <protocol>-<app>(如 http-web、grpc-api),便于 Istio 等服务网格识别协议。
3.4 ConfigMap —— 非敏感配置管理
ConfigMap 用于存储非敏感配置数据,合规要点包括:
- 数据大小限制:单个 ConfigMap 不应超过 1MB,避免 etcd 压力。
- 不可变配置:对于生产环境,设置
immutable: true防止意外修改。 - 挂载方式:优先使用
subPath挂载单个文件,而非整个卷,避免覆盖目录。 - 环境变量注入:使用
valueFrom.configMapKeyRef时,必须设置optional: false确保配置必达。
# 不可变 ConfigMap 示例
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
immutable: true
data:
app.properties: |
log.level=INFO
max.connections=100
database.url: jdbc:mysql://db-internal:3306/app
3.5 Secret —— 敏感数据安全基线
Secret 是合规检查的重中之重,任何泄露都可能导致严重安全事件:
| 检查项 | 合规标准 | 违规示例 |
|---|---|---|
| 数据编码 | 必须使用 base64 编码(非加密),禁止明文 | 直接写入纯文本字符串 |
| 静态加密 | 集群必须启用 EncryptionConfiguration |
Secret 以明文存储在 etcd 中 |
| 访问控制 | 使用 RBAC 限制 Secret 的 get/list 权限 | ServiceAccount 拥有集群级别 Secret 访问权 |
| 外部密钥管理 | 推荐集成 External Secrets Operator 或 Vault | 将生产密钥硬编码在 YAML 中 |
| 自动轮换 | 证书类 Secret 应设置 rotate 策略 |
TLS 证书过期未更新 |
⚠️ 常见陷阱:Secret 的
data 字段要求 base64 编码,但 stringData 字段允许明文写入。在 GitOps 场景中,务必使用 sops 或 sealed-secrets 加密整个 Secret 对象,而非仅依赖 base64。
3.6 RBAC —— 权限模型与最小授权
RBAC(基于角色的访问控制)是 Kubernetes 安全的核心防线。合规核验需覆盖以下四个对象:
- Role / ClusterRole:定义权限规则,必须遵循“最小权限”原则,禁止使用
*通配符。 - RoleBinding / ClusterRoleBinding:将角色绑定到用户或 ServiceAccount,必须明确绑定范围。
- 聚合规则:使用
aggregationRule动态组合 ClusterRole,避免手动维护庞大权限列表。 - 自动化的权限审计:定期使用
kubectl auth can-i --list或工具(如rbac-lookup)检查有效权限。
# 最小权限 Role 示例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: app-team
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "update"]
3.7 NetworkPolicy —— 微隔离与流量管控
NetworkPolicy 实现 Kubernetes 原生的微隔离,合规核验要点:
| 策略维度 | 合规要求 | 常见缺失 |
|---|---|---|
| 默认拒绝 | 每个命名空间应有一条 Deny All 基线策略 |
未设置任何 NetworkPolicy,导致全通 |
| 入站规则 | 明确允许的来源(namespaceSelector / podSelector) | 使用 ipBlock: 0.0.0.0/0 |
| 出站规则 | 仅允许必要的 DNS(port 53)和业务端口 | 未限制出站,Pod 可访问任意外部 IP |
| 策略顺序 | NetworkPolicy 是累加允许,无需担心顺序 | 误以为策略有优先级 |
| CNI 兼容性 | 确认集群 CNI 支持 NetworkPolicy(Calico/Cilium) | Flannel 默认不支持 |
环境一致性实践:在开发环境可使用宽松策略(允许全通),但 staging 和 production 必须启用严格默认拒绝。通过
policyTypes 字段显式声明入站/出站管控范围,避免因 CNI 实现差异导致策略失效。
3.8 配置对象合规核验清单总表
以下清单可作为日常巡检与 CI/CD 门禁的检查依据:
| 资源类型 | 必检字段 | 合规阈值 | 自动化工具 |
|---|---|---|---|
| Pod | securityContext, resources, imagePullPolicy | runAsNonRoot=true, limits 存在 | kube-bench, Polaris |
| Deployment | strategy, revisionHistoryLimit, minReadySeconds | RollingUpdate, history≥3 | kube-score, Conftest |
| Service | type, ports.name, selector | 禁止 NodePort 暴露内部服务 | kube-linter |
| ConfigMap | immutable, 数据大小 | 生产环境 immutable=true | kubeval, OPA Gatekeeper |
| Secret | 加密配置, RBAC 绑定, 外部密钥集成 | etcd 加密启用, 无通配符权限 | kube-bench, Checkov |
| RBAC | rules.verbs, 绑定范围, aggregationRule | 禁止 cluster-admin 给普通 SA | rbac-lookup, kubectl auth can-i |
| NetworkPolicy | 默认拒绝策略, 入站/出站规则 | 每个 NS 至少一条 Deny All | Calico Policy Validator, Cilium |
核验自动化建议:将上述清单编码为 OPA Gatekeeper 约束模板或 Kyverno 集群策略,在资源创建时即拦截不合规配置。同时,在 CI 流水线中集成
kube-score 和 conftest,对 YAML 清单进行静态扫描。