Detecting Zero Trust Policy Drift with Gatekeeper Using Warn Mode

Introduction

In the previous article, Implementing Zero Trust with Istio Authorization Policies, we enforced Zero Trust at runtime. Istio decided which workloads could talk to each other.

In this post, we move one step left in the supply chain.
We’ll use Gatekeeper, the admission controller built on Open Policy Agent (OPA), to detect and warn about policy drift before it reaches production but without blocking developer velocity.

This is where the enforcementAction: warn setting comes in.

What You’ll Learn

• How to install Gatekeeper (via CLI and Helm)
• How to create a Gatekeeper ConstraintTemplate
• How to use enforcementAction: warn to safely detect drift
• How to interpret warnings and tune your rollout

Step 1: Install the Gatekeeper CLI

The Gatekeeper CLI helps you:

• Test ConstraintTemplates locally
• Validate Rego before deploying
• Run policy audits offline

Install manually:

Verify the installation:

You should see output similar to:

GitVersion:    v3.15.1
GitCommit:     3350319f76d3e2d78df0b972c63258cba7c7915f
GitTreeState:  clean
BuildDate:     2024-03-12T23:23:33Z
GoVersion:     go1.21.8
Compiler:      gc
Platform:      darwin/arm64

gator is the local Gatekeeper CLI that you’ll use to test constraints before applying them to your cluster.

Step 2: Deploy Gatekeeper to Your Cluster

If you’re using Minikube, install Gatekeeper via Helm:

Verify the deployment:

All pods should be in Running state:

NAME                                           READY   STATUS    RESTARTS   AGE
gatekeeper-audit-7c6f4b8cc8-9qlwk              1/1     Running   0          1m
gatekeeper-controller-manager-5c7b474c9d-vp9ml 1/1     Running   0          1m

Step 3: Create a Gatekeeper ConstraintTemplate

This defines the Rego logic for detecting overly permissive Istio AuthorizationPolicy resources.

Apply it:

Step 4: Create a “Warn” Constraint

Instead of blocking, we’ll configure Gatekeeper to warn when a bad policy is applied.

Apply it:

Step 5: Test It

Create a weak policy:

Apply it:

Gatekeeper won’t block it but you’ll see a warning:

Warning: admission.gatekeeper.sh: AuthorizationPolicy default/wildcard-policy allows all principals ('*')
authorizationpolicy.security.istio.io/wildcard-policy created

Step 6: Verify Warnings and Violations

Check Gatekeeper logs and audit results:

Or, for full audits:

The CLI will output the same violations locally without touching the cluster.

Best Practices for “Warn” Mode

Stage	Enforcement Mode	Purpose
Policy Development	dryrun	Safely test new constraints
Pre-Production	warn	Educate teams, collect metrics
Production Hardened	deny	Enforce Zero Trust strictly

Adopt a progressive hardening workflow:

• Write policies and run gator test locally.
• Apply them in cluster with warn.
• Once you’ve fixed all warnings, flip to deny.

Step 7: Clean Up

Conclusion

enforcementAction: warn gives you visibility without friction.
Instead of stopping developers, it educates them, surfacing misconfigurations early and building security awareness over time.

By combining:

• Istio (runtime enforcement), and
• Gatekeeper (admission-time detection),

you get a complete Zero Trust feedback loop.
Add the CLI (gator) and you can test everything locally before pushing to GitOps or CI/CD.