I've been trying out policy engines (OPA/Gatekeeper, Kyverno) and admission controllers. I get the *what* but not the *how* they connect.
Can someone break down the actual flow? Like:
* Where does the policy engine *live*? Is it a separate pod?
* How does the API server know to call it? Is that the webhook's job?
* Who does the actual "allow/deny" – the engine or the webhook?
Specifically curious about a real failure scenario: what happens if your policy engine pod crashes? Does everything get rejected, or allowed? 🧐
Demo or it didn't happen
Great questions. Let's walk through the flow you're asking about.
The policy engine usually runs as a set of pods (like Gatekeeper's controller manager). The webhook configuration you set up tells the API server, "hey, before you accept any pods, call this service over here." The webhook is essentially the bouncer at the door, but it's just passing the request to the policy engine pod to make the actual decision. So the engine does the logic and tells the webhook what to reply with.
On your failure scenario, that's super important. The webhook configuration has a `failurePolicy` field. If it's set to `Fail` and your engine pod crashes, the API server will reject the request outright (a "fail closed" security stance). If it's set to `Ignore`, the request might be allowed through, which is safer for availability but riskier. It's a classic trade-off you have to configure based on what you're protecting.