Die Oberfläche ist lokalisiert; Skill-Beschreibungen und -Dokumente werden per KI automatisch in Ihre Sprache übersetzt. Code, Befehle, Pfade und Fachbegriffe bleiben im Original, maßgeblich ist das Dokument des Autors.
Use when the user asks about policy as code, OPA, Rego, Kyverno, admission controllers, policy enforcement, compliance as code, guardrails, or policy-based governance in Kubernetes/cloud. Covers: OPA/Rego policy writing, Gatekeeper constraint templates, Kyverno cluster policies, policy testing (conftest, opa test), CI/CD policy integration, mutation policie…
Independent GitHub snapshot · Automated classification · Original documentation governs
name: devops-policy-as-code
description: >
Use when the user asks about policy as code, OPA, Rego, Kyverno, admission
controllers, policy enforcement, compliance as code, guardrails, or
policy-based governance in Kubernetes/cloud. Covers: OPA/Rego policy writing,
Gatekeeper constraint templates, Kyverno cluster policies, policy testing
(conftest, opa test), CI/CD policy integration, mutation policies, policy
reporting, and compliance automation.
Do NOT use for: general compliance (enterprise-compliance-audit), security
scanning (security-sast-dast), or RBAC design.
version: "2.0.0"
author: "j4flmao"
license: "MIT"
compatibility:
claude-code: true
cursor: true
codex: true
windsurf: true
tags: [devops, policy-as-code, opa, kyverno, gatekeeper, phase-3]
Policy as Code
Purpose
Implement policy as code using OPA/Rego and Kyverno: write admission policies, enforce guardrails, validate configurations, and automate compliance checks in Kubernetes and cloud environments. Covers mutating and validating policies, constraint templates, policy testing, CI/CD integration, and policy lifecycle management.
Rego policy code, Kyverno ClusterPolicy YAML, constraint template YAML, or test files. No preamble. No postamble. No filler.
Completion Criteria
Policy framework selected (OPA/Gatekeeper, Kyverno, or hybrid)
Core security policies defined (privileged containers, host networking, resource limits)
Compliance policies defined (labels, annotations, encryption, network policies)
Mutation policies defined (default labels, sidecar injection, resource defaults)
Policy tests written and passing
CI/CD integration established (conftest for IaC, admission for K8s)
Policy reporting and monitoring configured
Policy lifecycle management defined (review cadence, versioning)
Architecture / Decision Trees
Policy Engine Decision Tree
What kind of policies?
Kubernetes admission only → Kyverno (K8s-native, YAML-based, or)
OPA Gatekeeper (Rego-based, more flexible)
Multi-platform (K8s + Terraform + CI/CD + API gateways) → OPA (broadest support)
Team familiarity with Rego?
Low/None → Kyverno (YAML policies, no new language)
Moderate/High → OPA/Gatekeeper (more expressive, steeper learning curve)
Mutation policies needed?
YES → Kyverno (native mutation support) or OPA with mutating webhook
NO → Both work well
Background scanning needed?
YES → Kyverno (built-in background scan, policy reports)
NO → Both work well
Multi-cluster federation?
YES → OPA Gatekeeper (constraint template distribution) or Kyverno with GitOps
NO → Either
Policy Categories
Category
Examples
Engine
Priority
Security
No privileged containers, no hostNetwork, read-only root FS
# Policy versioning and promotion
# policies/
# ├── development/ # Enforced in dev, audit in prod
# │ ├── require-labels.rego
# │ └── require-resources.rego
# ├── staging/ # Enforced in staging
# │ ├── block-privileged.yaml
# │ └── require-probes.yaml
# └── production/ # Enforced in production
# ├── block-privileged.yaml
# ├── require-resources.yaml
# ├── require-probes.yaml
# ├── require-network-policies.yaml
# ├── require-encryption.yaml
# └── block-insecure-registries.yaml
# Promotion gates:
# development → audit only, no blocking
# staging → enforce core security, audit extras
# production → enforce all security + compliance
Production Considerations
Performance and Scaling
OPA/Gatekeeper:
- Constraint evaluation < 1ms per admission request
- Gatekeeper controller: 1 CPU, 512Mi for 50+ constraints
- Max 100 constraints per controller recommended
- Cache size monitoring: gatekeeper_constraints
Kyverno:
- Policy evaluation < 5ms per admission request
- Kyverno controller: 2 CPU, 1Gi for 50+ policies
- Webhook timeout: 10s (configurable via failurePolicy)
- Background scanning cadence: every 8h default
Both:
- Use failurePolicy: Ignore for non-critical policies (prevents cluster outage)
- Monitor webhook latency and failure rates
- Set resource limits on policy controllers
- Avoid overloading with too many webhooks (>50 policies per controller)
Security Considerations
- Admission webhooks can block cluster operations if misconfigured
→ Always test policies in Audit mode first
→ Use failurePolicy: Fail for security policies
→ Use failurePolicy: Ignore for cosmetic/compliance policies
→ Exclude kube-system from restrictive policies
- Policy engine compromise is cluster compromise
→ Restrict access to policy CRDs (constraint templates)
→ Use separate service accounts for policy controllers
→ Audit policy changes via Kubernetes audit log
- Policy as code in CI/CD prevents bad configs from reaching the cluster
→ Run conftest in pre-commit hooks for immediate feedback
→ Run conftest in CI for PR validation
→ Run admission webhooks in cluster for defense-in-depth
Common Pitfalls
Too many blocking policies: Developers will push back. Start with 5 core security policies, add more gradually.
No Audit mode first: Every policy should run in Audit mode for 2 weeks before switching to Enforce.
Ignoring performance: Each admission webhook adds 3-5ms latency. Group related policies into fewer webhooks.
Policy sprawl: 100+ small policies are harder to manage than 20-30 focused policies.
Missing policy tests: Untested Rego code has bugs. Every policy needs tests covering pass and fail cases.
No policy review cadence: Policies become stale. Review every quarter with stakeholders.
Overly broad matching: A policy matching all kinds can break CRD controllers. Scope policies to specific kinds.
Forgetting exclusions: Admission webhooks need to exclude control plane components (kube-system, istio-system).
Drift between environments: Policies in dev, staging, and prod should be version-controlled and promoted.
No policy alerting: Policy violations must alert the platform team, even in Audit mode.
Compared With
Aspect
OPA/Gatekeeper
Kyverno
jsPolicy
Policy language
Rego (declarative)
YAML (no new language)
JavaScript/TypeScript
Learning curve
High
Low
Medium
Mutation support
Custom webhook
Native
Native
Background scan
External tooling
Built-in
Limited
Policy testing
opa test (built-in)
kyverno test (built-in)
Jest
CI/CD integration
conftest
kyverno-json
Custom
Multi-platform
K8s, Terraform, API, Envoy, Cloud
K8s-native
K8s-native
Community size
Very Large
Large
Small
Ecosystem tools
Conftest, Gatekeeper, Envoy
kyverno-json, Policy Reporter
Limited
Performance
<1ms per rule
<5ms per policy
<10ms per policy
References
references/kyverno-policies.md — Kyverno Policies
references/opa-k8s-admission.md — OPA Gatekeeper for Kubernetes Admission Control
references/opa-policy-language.md — OPA/Rego Deep Dive
references/policy-as-code-advanced.md — Policy As Code Advanced Topics
references/policy-as-code-fundamentals.md — Policy As Code Fundamentals
references/policy-ci-cd.md — Policy-as-Code in CI/CD