Policy Engines

← Back to all decks

21 cards — 🟢 3 easy | 🟡 4 medium | 🔴 3 hard

🟢 Easy (3)

1. What is the fundamental difference between Kubernetes RBAC and a policy engine like OPA Gatekeeper or Kyverno?

Show answer

RBAC controls who can perform an action (identity-based, e.g., "can this user create a Deployment?"). Policy engines control what content is allowed (content-based, e.g., "does this Deployment have resource limits?").

Example: OPA evaluates "Can user X deploy to production?" by checking a Rego policy against input JSON. Decouples policy from application code.

Remember: "OPA = universal policy brain, Rego = its language."

Name origin: OPA = Open Policy Agent. Created by Styra, donated to CNCF. Graduated project since 2021.

2. What are the four policy types that Kyverno supports?

Show answer

Validate (block or warn on non-compliant resources), Mutate (automatically modify resources), Generate (auto-create companion resources), and VerifyImages (check container image signatures).

Example: deny[msg] { input.request.kind.kind == "Pod"; not input.request.object.spec.securityContext.runAsNonRoot; msg := "Pods must run as non-root" }

Remember: "Rego = query language, not imperative. Think SQL for policies."

Remember: "VMGV = Validate, Mutate, Generate, VerifyImages." Kyverno\'s four superpowers.

3. What is the difference between Enforce and Audit mode for policy engines?

Show answer

Enforce mode rejects non-compliant resources at admission time, preventing them from being created. Audit mode allows the resources but logs violations for review, letting you assess impact before enforcing.

Example: package kubernetes.admission -- violation[{"msg": msg}] { ... } — Gatekeeper watches admission requests and rejects those matching violation rules.

Remember: "OPA = library, Gatekeeper = K8s-native OPA with CRDs."

Remember: "Audit first, enforce second." Rolling out enforcement without auditing first will block legitimate workloads.

🟡 Medium (4)

1. In OPA Gatekeeper, what are the two resources needed to define and apply a policy?

Show answer

A ConstraintTemplate (defines the policy logic in Rego) and a Constraint (applies the template with specific parameters and match criteria). The template defines what to check; the constraint defines where to check it and with what parameters.

Gotcha: Test policies with opa test before deploying. A bad policy can block all deployments.

Example: opa eval -i input.json -d policy.rego "data.example.allow"

2. What are two key differences between OPA Gatekeeper and Kyverno in terms of policy language and mutation support?

Show answer

OPA Gatekeeper uses Rego (a custom DSL with a steep learning curve) and has limited mutation support. Kyverno uses native YAML (low learning curve) and has first-class mutation and resource generation capabilities.

Remember: "Conftest = OPA for config files." It catches misconfigurations before they reach the cluster.

Example: conftest test --policy ./policy deployment.yaml

Interview tip: Choose Kyverno for K8s-only, YAML-native policies. Choose OPA for cross-system policies (K8s + CI + APIs).

3. How does a Kyverno mutate policy work? Give an example use case.

Show answer

A mutate policy automatically modifies resources as they are admitted. For example, a patchStrategicMerge rule can add default labels (managed-by: kyverno, environment: {{request.namespace}}) to every Pod created, without requiring developers to add them manually.

Example: A ConstraintTemplate defines the Rego logic; a Constraint applies it to specific resources. Think of templates as policy classes and constraints as instances.

Remember: "Template = schema + logic, Constraint = where to apply it."

Example: Auto-add `managed-by: kyverno` label to every Pod. Developers never need to remember — the policy handles it.

4. What are the three Pod Security Standards levels in Kubernetes, and what does each allow?

Show answer

Privileged: everything (no restrictions). Baseline: prevents known privilege escalations. Restricted: strongly restricted (non-root, no capabilities, read-only root filesystem). They are applied via namespace labels like pod-security.kubernetes.io/enforce=restricted.

Remember: "Shift-left = catch earlier, fail faster." Policy in CI means broken configs never reach staging.

Example: conftest test in a GitHub Actions step blocks PRs with policy violations.

Timeline: Pod Security Standards replaced the deprecated PodSecurityPolicy in Kubernetes 1.25 (2022).

🔴 Hard (3)

1. In Rego, how would you write a policy to deny containers using the :latest image tag or no tag at all?

Show answer

Two violation rules: one checks endswith(container.image, ":latest") and another checks not contains(container.image, ":") (which defaults to latest). Both iterate over input.review.object.spec.containers[_] and return a violation message with the container name.

Gotcha: OPA bundles update periodically — there is a propagation delay. For real-time policy changes, reduce the bundle polling interval.

Example: OPA can pull bundles from S3, GCS, or an HTTP server.

2. How does a Kyverno generate policy work, and why is auto-generating a default-deny NetworkPolicy on namespace creation valuable?

Show answer

A generate rule triggers when a matched resource is created (e.g., a Namespace) and automatically creates another resource (e.g., a NetworkPolicy with empty podSelector and Ingress+Egress policyTypes). This ensures every new namespace starts with network segmentation by default, closing the gap between namespace creation and security hardening.

Example: Sentinel policy: main = rule { all tfplan.resources.aws_instance as _, instances { instances.applied.instance_type in ["t3.micro", "t3.small"] } }

Sentinel vs OPA: Sentinel is HashiCorp-only; OPA is vendor-neutral and open source.

Remember: "Generate = auto-create companion resources." Most commonly: auto-create NetworkPolicy on namespace creation.

3. What is the recommended rollout strategy for policy engines, and why is setting failurePolicy: Ignore important?

Show answer

Deploy policies in Audit mode first, review violations, fix existing non-compliant resources, then switch to Enforce. Setting failurePolicy: Ignore on the webhook is important because if the policy engine (Kyverno/Gatekeeper) goes down, the webhook would otherwise block all resource creation cluster-wide.

Gotcha: `failurePolicy: Fail` means if Gatekeeper/Kyverno crashes, ALL resource creation is blocked cluster-wide. Use `Ignore` with compensating audit controls.