policy-as-code

策略即代码的准入控制与流水线门禁

补充说明

策略即代码把安全、合规和资源规范写成可测试、可版本化的规则，在 CI 和集群准入两个层面执行。CI 层反馈快，准入层是最后防线；只做其中一层都会漏。

上线顺序必须是 audit → warn → deny，每阶段至少观察一到两周。例外必须有 owner、范围和到期日。

常用示例

Gatekeeper ConstraintTemplate：

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresources
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResources
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredresources

        violation[{"msg": msg}] {
          c := input.review.object.spec.containers[_]
          not c.resources.limits.memory
          msg := sprintf("container %v missing memory limit", [c.name])
        }

对应 Constraint：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResources
metadata:
  name: require-memory-limit
spec:
  enforcementAction: deny
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]

CI 层检查：

conftest test manifests/ --policy policy/ --output table
conftest verify --policy policy/
kyverno apply policy.yaml --resource deployment.yaml
kyverno test .

推广阶段与退出条件：

例外规则：

• 最长 30 天，必须写明原因、影响范围和到期日。
• 只允许命名空间级例外，不允许全局关闭策略；到期自动失效，续期需重新审批。

易错点与排错

• 直接上 deny，没有 audit 阶段，把正常发布打挂。
• 排除命名空间范围过大（整个 kube-system 或 prod），策略形同虚设。
• 策略没有测试用例，改规则时误伤存量工作负载。
• 只做准入不做 CI，反馈太晚，开发者不知道哪条规则失败。
• 例外永久有效，无人回收，最终例外比规则还多。
• 策略只匹配旧 API 版本（extensions/v1beta1），升级后失效。
• 忽略 initContainers 和 ephemeralContainers，容器被绕过。
• 准入 webhook 超时或 failurePolicy 设置不当，导致集群无法创建 Pod。

读完自测

合上页面，先回答，再展开对照。

1. 为什么策略要先 audit 再 deny？
2. CI 层和准入层各自解决什么问题？
3. 一个合格的策略例外至少包含哪些信息？

相关条目

• gatekeeper — OPA 准入控制
• kyverno — Kubernetes 原生策略
• conftest — CI 策略测试
• tfsec — Terraform 安全扫描
• pod-security-admission — Pod 安全标准