Policy Engines for Platform Governance

CNPA Domain: Platform Observability, Security, and Conformance (20%) Topic: Policy Engines for Platform Governance

Overview

Platform governance requires enforcing organizational standards consistently across every workload, namespace, and team. Policy engines automate this enforcement by intercepting Kubernetes API requests and validating them against defined rules — before resources are ever created.

Without policy engines, platform teams rely on documentation, code reviews, and hope. With them, guardrails are enforced at the API layer.

---

Kubernetes Admission Control

Policy engines plug into the Kubernetes API server via admission webhooks:

kubectl apply -f deployment.yaml
     ↓
Kubernetes API Server
     ↓
[Authentication] → [Authorization (RBAC)] → [Admission Control]
                                                     ↓
                                         ┌───────────────────────┐
                                         │  Validating Webhooks  │ ← Policy Engine
                                         │  Mutating Webhooks    │ ← Policy Engine
                                         └───────────────────────┘
                                                     ↓
                                            etcd (persisted)

Mutating webhooks can modify resources (e.g., inject sidecars, set defaults). Validating webhooks accept or reject resources based on rules.

---

OPA / Gatekeeper

Open Policy Agent (OPA) is a general-purpose policy engine. OPA Gatekeeper is its Kubernetes-native integration.

Policies are written in Rego — a purpose-built policy language.

Gatekeeper Architecture

ConstraintTemplate  →  Defines the policy logic (Rego)
Constraint          →  Instantiates the policy with parameters

Example: Require Resource Limits on All Containers

# ConstraintTemplate: defines the policy
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresourcelimits
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResourceLimits
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredresourcelimits

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("Container '%s' must have CPU limits", [container.name])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.limits.memory
          msg := sprintf("Container '%s' must have memory limits", [container.name])
        }

# Constraint: enforce the policy in specific namespaces
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResourceLimits
metadata:
  name: require-resource-limits
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment", "StatefulSet"]
    namespaceSelector:
      matchLabels:
        policy.example.com/enforce: "true"

---

Kyverno

Kyverno is a Kubernetes-native policy engine that uses YAML-based policies — no Rego required.

Policy Types

Type	Use Case
Validate	Reject non-compliant resources
Mutate	Auto-patch resources (add labels, set defaults)
Generate	Create related resources (e.g., NetworkPolicy on Namespace creation)
VerifyImages	Enforce container image signatures

Example: Disallow latest Image Tag

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
  annotations:
    policies.kyverno.io/description: >-
      Require container images to specify a tag other than 'latest'.
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Image tag 'latest' is not allowed. Use a specific version."
        pattern:
          spec:
            containers:
              - image: "!*:latest"
            initContainers:
              - image: "!*:latest"

Example: Auto-Generate NetworkPolicy for New Namespaces

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-networkpolicy
spec:
  rules:
    - name: default-deny-ingress
      match:
        any:
          - resources:
              kinds: [Namespace]
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny-ingress
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}
            policyTypes: [Ingress]

---

OPA Gatekeeper vs Kyverno

Aspect	OPA Gatekeeper	Kyverno
Policy language	Rego	YAML
Learning curve	Steep (Rego)	Low (YAML)
Flexibility	Very high	High
Mutation	Limited	Strong
Image verification	Via external tools	Built-in
Audit mode	✅	✅
Community	CNCF graduated	CNCF graduated

Guidance: Use Kyverno for most Kubernetes-native governance use cases. Use OPA for complex multi-system policy needs.

---

Policy-as-Code Patterns

Audit Mode vs Enforce Mode

# Kyverno
validationFailureAction: Audit    # Log violations, don't block
validationFailureAction: Enforce  # Block non-compliant resources

# Gatekeeper
enforcementAction: dryrun         # Log only
enforcementAction: deny           # Block
enforcementAction: warn           # Warn but allow

Best practice: Start in Audit mode to find violations, then switch to Enforce once policies are refined.

Policy Library

Platform teams maintain a policy library in Git:

platform-policies/
├── security/
│   ├── disallow-privileged-containers.yaml
│   ├── require-pod-security-labels.yaml
│   └── disallow-latest-tag.yaml
├── networking/
│   ├── require-network-policy.yaml
│   └── disallow-host-network.yaml
├── resources/
│   ├── require-resource-limits.yaml
│   └── require-labels.yaml
└── images/
    ├── require-image-signing.yaml
    └── allow-registry-list.yaml

Policies are deployed via GitOps alongside application workloads.

---

Key Takeaways

• Policy engines plug into admission webhooks to validate/mutate resources before they're accepted into the cluster

• OPA Gatekeeper uses Rego for flexible, powerful policy logic suited for complex rules

• Kyverno uses YAML policies — lower barrier to entry, strong mutation and generate capabilities

• Start policies in Audit mode to measure compliance before enforcing

• Treat policies as code — version-controlled, reviewed, deployed via GitOps

• Generate policies in Kyverno can automatically create companion resources (NetworkPolicies, ResourceQuotas) when namespaces are created

---

Further Reading

• OPA Gatekeeper Documentation

• Kyverno Documentation

• CNCF Policy Working Group

• Kyverno Policy Library

• → Next: Kubernetes Security Essentials