# OPA Gatekeeper — Policy Controller for Kubernetes Admission

> OPA Gatekeeper enforces customizable policies on Kubernetes resources at admission time, using constraint templates written in Rego to validate and mutate API requests.

## Install

Save as a script file and run:

# OPA Gatekeeper — Policy Controller for Kubernetes Admission

## Quick Use
```bash
# Install Gatekeeper via Helm
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper gatekeeper/gatekeeper --namespace gatekeeper-system --create-namespace
# Apply a constraint template
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/general/allowedrepos/template.yaml
# Create a constraint
kubectl apply -f my-allowed-repos-constraint.yaml
```

## Introduction
OPA Gatekeeper brings the Open Policy Agent (OPA) into the Kubernetes admission control flow as a native validating and mutating webhook. Instead of writing policies in raw OPA configurations, Gatekeeper introduces Kubernetes-native CRDs — ConstraintTemplates and Constraints — that make policy management declarative and auditable.

## What OPA Gatekeeper Does
- Validates Kubernetes API requests against custom policies before resources are persisted
- Mutates resources to inject defaults, labels, or annotations according to policy
- Audits existing cluster resources for policy violations on a configurable schedule
- Provides a library of reusable constraint templates for common governance patterns
- Reports policy violation status through Kubernetes resource conditions and events

## Architecture Overview
Gatekeeper runs as a Kubernetes deployment that registers itself as a validating and mutating admission webhook. When the API server receives a create/update/delete request, it sends an admission review to Gatekeeper. Gatekeeper evaluates the request against compiled Rego policies from ConstraintTemplates and returns allow/deny decisions. The audit controller periodically scans existing resources for retroactive compliance checks.

## Self-Hosting & Configuration
- Install via Helm chart or raw manifests from the Gatekeeper releases
- Define ConstraintTemplates with Rego policy logic, then instantiate Constraints to activate them
- Configure the webhook to target specific API groups, kinds, and namespaces using match rules
- Use the `Config` CRD to sync external data (e.g., all namespaces, ingresses) into OPA for cross-resource policies
- Set `--audit-interval` to control how frequently existing resources are checked for violations

## Key Features
- Constraint template library with pre-built policies for image registries, labels, resource limits, and more
- External data support for policies that reference resources outside the admission request
- Mutation support for injecting sidecar annotations, default labels, or enforcing naming conventions
- Dry-run enforcement action for testing policies without blocking deployments
- Prometheus metrics for policy evaluation latency, violation counts, and webhook health

## Comparison with Similar Tools
- **Kyverno** — Kubernetes-native policy engine using YAML instead of Rego, lower learning curve
- **OPA (standalone)** — general-purpose policy engine; Gatekeeper adds Kubernetes-specific CRDs and audit
- **Kubewarden** — policy engine using WebAssembly, supporting policies in multiple languages
- **Polaris** — best-practice validation focused on workload configuration, less customizable
- **Pod Security Standards** — built-in Kubernetes admission control, limited to pod security

## FAQ
**Q: Do I need to learn Rego to use Gatekeeper?**
A: Writing custom ConstraintTemplates requires Rego. However, the community-maintained library provides many ready-to-use templates that only need parameter configuration.

**Q: What happens if Gatekeeper is unavailable?**
A: By default, the webhook is configured with `failurePolicy: Ignore`, so API requests proceed if Gatekeeper is down. This can be changed to `Fail` for stricter enforcement.

**Q: Can Gatekeeper mutate resources?**
A: Yes. Gatekeeper supports mutation through Assign, AssignMetadata, and ModifySet CRDs for injecting or modifying fields on resources during admission.

**Q: How does audit differ from admission?**
A: Admission blocks non-compliant resources at creation time. Audit periodically scans already-existing resources and reports violations without modifying them.

## Sources
- https://github.com/open-policy-agent/gatekeeper
- https://open-policy-agent.github.io/gatekeeper/

---
Source: https://tokrepo.com/en/workflows/asset-a2c88cdc
Author: Script Depot