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 实现差异导致策略失效。
Kubernetes 核心配置对象关系图 Pod Deployment Service ConfigMap Secret RBAC (Role/ClusterRole) NetworkPolicy 说明:实线表示直接控制/选择关系,虚线表示安全管控关系。合规核验需覆盖所有连线两端对象的配置一致性。

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 清单进行静态扫描。
配置对象合规核验流程 1. 获取资源清单 kubectl get / YAML 文件 2. 字段合规扫描 kube-score / Conftest 3. 策略引擎校验 OPA / Kyverno 4. 生成报告 Pass/Fail ✅ 通过 ❌ 拒绝 说明:该流程可嵌入 CI/CD 流水线(如 GitLab CI / GitHub Actions),在 merge 前阻断不合规配置进入集群。