Hi everyone. I'm just starting to learn about policy engines for our Kubernetes clusters. Everything I read says OPA Gatekeeper and Kyverno are the main options, but I'm getting overwhelmed 😅.
I manage a few AWS EKS clusters and my main goal is to enforce simple rules, like:
* Require a `team` label on all deployments
* Ensure no LoadBalancer services are created without approval
* Maybe check that container images come from our approved registry
From a beginner's perspective, they seem similar. Could someone show me a basic example of how you'd write the same rule (like the "team label" one) in both? Seeing actual YAML would help me understand the difference in approach.
Also, which one is easier to start with if my team only knows basic Terraform and Helm? I'm worried about picking something too complex to maintain.
You picked a perfect starting point. For your specific use cases, Kyverno is likely the better fit. Its policies are written as Kubernetes-native YAML, which maps directly to what you're already trying to control. Gatekeeper uses Rego, a separate policy language, which is a steeper learning curve.
Here's the "team label" example you asked for.
In Kyverno, it's a declarative rule:
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-team-label
spec:
validationFailureAction: Enforce
rules:
- name: check-team-label
match:
resources:
kinds:
- Deployment
validate:
message: "A 'team' label is required."
pattern:
metadata:
labels:
team: "?*"
```
For Gatekeeper, you need a ConstraintTemplate (written in Rego) and then a separate Constraint resource. The Rego logic is more general-purpose, which is powerful but overkill for simple label checks.
Given your team's familiarity with Terraform and Helm, Kyverno's YAML will feel more immediately accessible. The complexity isn't in the initial policy, but in the long tail of maintenance and edge cases. Kyverno simplifies that for the 80% case.
Right-size or die
You're absolutely right about the immediate accessibility of Kyverno's YAML for that initial 80% of simple rules. Having implemented both in client environments, I'd add that the maintenance overhead difference is even more pronounced than the initial learning curve.
Where teams often stumble with Gatekeeper isn't just learning Rego, it's the debugging cycle. A Kyverno policy failure typically outputs a clear Kubernetes-native error in the `Events` or policy status. Diagnosing why a Gatekeeper constraint failed means interpreting Rego trace logs, which adds a context-switching cost for every developer. That operational friction accumulates.
However, I'd gently push back on the idea that Rego is *always* overkill for label checks. Its power becomes relevant for your "LoadBalancer without approval" case if you need complex, multi-resource context. For example, a Rego policy could check if the requesting *user* is in an approved GitHub team *and* if the cluster has available IPs *before* allowing that Service. Kyverno would need multiple, separate policies and possibly external data to achieve the same compound logic.
- Mike
You've already gotten a great side-by-side example. For your team's background, the Kyverno YAML approach will feel much closer to the Helm charts you already manage.
One practical aspect to consider is how each tool handles that "approval" workflow for LoadBalancer services. With Kyverno, you'd typically use a generate rule to create a temporary NetworkPolicy or similar, keeping it within the Kubernetes resource model. Gatekeeper can do it, but you're back to crafting the correct Rego to modify objects.
Given your stated goals, starting with Kyverno is a clear win for immediate productivity. The risk with Gatekeeper is hitting a wall when you need a slightly more complex policy, requiring a deep dive into Rego while your actual task waits.