Skip to content

Portal | Level: L2: Operations | Topics: Policy Engines | Domain: Kubernetes

Policy Engines - Skill Check

Mental model (bottom-up)

RBAC controls who can act. Policy engines control what can exist. They enforce organizational standards at the API admission level using webhooks.

Visual stack

[kubectl apply    ]  user submits resource
|
[Authentication   ]  who are you? (RBAC)
|
[Admission Control]  should this resource be allowed? (Kyverno/Gatekeeper)
|
  [Mutate         ]  auto-add labels, defaults
  [Validate       ]  reject if no limits, wrong registry, privileged
  [Generate       ]  auto-create companion resources
|
[etcd             ]  resource stored

Glossary

  • Kyverno - YAML-based policy engine; validate, mutate, generate
  • OPA Gatekeeper - Rego-based policy engine; validate only (primarily)
  • Rego - OPA's policy language (DSL)
  • Audit mode - log violations without blocking
  • Enforce mode - reject non-compliant resources
  • Pod Security Standards - built-in K8s admission (Privileged/Baseline/Restricted)

Core questions (easy -> hard)

  • RBAC vs policy engines?
  • RBAC: can user create pods? Policy: should this specific pod be allowed?
  • Kyverno vs Gatekeeper?
  • Kyverno: YAML, mutation+generation. Gatekeeper: Rego, cross-platform OPA ecosystem.
  • How do you safely roll out a new policy?
  • Audit mode first. Review violations. Fix existing resources. Then Enforce.
  • What happens if the policy webhook goes down?
  • failurePolicy=Fail: blocks all resources. failurePolicy=Ignore: allows unchecked.
  • What policies should every cluster have?
  • Require limits, disallow privileged, restrict registries, require non-root, require labels.
  • How do you handle exceptions?
  • Kyverno PolicyException CR. Gatekeeper excludedNamespaces. Always document why.

Wiki Navigation

Prerequisites

Related Content