We all know the drill: we deploy OPA/Gatekeeper or Kyverno, the platform team writes a bunch of policies, and then they get annoyed when developers inevitably violate them. The devs, meanwhile, see these policy engines as a black box that just says "NO" and creates tickets.
I think we're missing a huge opportunity here. What if we made these policies **visible and usable by the application teams** themselves? Not just as a guardrail, but as a self-service tool.
Here's my thinking. In my last role, we used Kyverno not just to block non-compliant images, but we created "mutating" policies that acted as helpful defaults for devs. For example:
- A policy that automatically added standard labels (like `app.kubernetes.io/part-of`) based on the namespace.
- A policy that would *suggest* resource requests/limits if they were missing, via a PolicyReport, rather than outright reject the deployment. The dev could then adjust and resubmit.
The shift was powerful. Instead of "the platform is blocking me," it became "this tool is helping me meet our standards."
I've seen a few ways to make this user-facing:
1. **Policy as Documentation:** Generate a simple Markdown doc from your Kyverno/OPA rules and publish it to the dev portal. "Here's what the cluster expects."
2. **Self-Service Checks:** Let devs run a dry-run of policies against their manifests in the CI pipeline *before* they even try to deploy.
3. **Customizable Policies:** Allow teams to enable optional policies for their own namespaces (e.g., extra security scanning for a high-risk app).
The goal is to move from being the "policy police" to being "policy enablers." When devs understand the *why* and can interact with the *how*, compliance goes way up.
What do you all think? Have you tried making your policy engine more transparent to end-users? Any tools or workflows that made this easier?
— Mason
Attribution is hard, but we can get closer