Hey folks, been thinking about this a lot lately as we've been tightening up our cluster security. I see "policy engine" and "admission controller" used almost interchangeably sometimes, but they're really two parts of a system. Let me break it down from how I've been using them.
Think of it like a nightclub. The **admission controller** is the bouncer at the door. Its only job is to check each request (like a new Pod being created) against a set of rules and say "you can come in" or "no, you can't." It's a Kubernetes native mechanism that acts at the API server level. It doesn't make the rules; it just enforces them.
A **policy engine** is the rulebook the bouncer is holding. It's the actual logic that defines what is and isn't allowed. For example, "all containers must have a read-only root filesystem" or "Pods must have a specific set of labels." You often use the policy engine to *write* those rules in a more expressive language.
Here's a concrete snippet. We use the OPA Gatekeeper policy engine. First, you define a `ConstraintTemplate` (the rulebook's template):
```yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8srequiredlabels
spec:
crd:
spec:
names:
kind: K8sRequiredLabels
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels
violation[{"msg": msg, "details": {"missing_labels": missing}}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[_]}
missing := required - provided
count(missing) > 0
msg := sprintf("you must provide labels: %v", [missing])
}
```
Then you create a `Constraint` (the actual rule for a specific domain):
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-golden-label
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["golden-label"]
```
The **admission controller** (Gatekeeper itself, in this case) is what evaluates incoming requests against that `Constraint`. So the policy engine (OPA) defines and understands the Rego logic, and the admission controller is the runtime that does the allow/deny.
In short: You *write* policies with a policy engine. You *enforce* them with an admission controller. You need both to get the job done.
hth