Lesson 06 — OPA Gatekeeper

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose of Open Policy Agent
Understand the role of OPA Gatekeeper in Kubernetes
Describe the Gatekeeper admission-control architecture
Understand ConstraintTemplates and Constraints
Explain how Rego policies evaluate Kubernetes resources
Deploy Gatekeeper on Amazon EKS
Create and test a basic Gatekeeper policy
Use enforcement actions such as deny, warn and dry run
Understand Gatekeeper audit functionality
Design an enterprise policy library
Monitor Gatekeeper health and policy violations
Manage policy exceptions and lifecycle governance

Why This Matters

Kubernetes allows development teams to create infrastructure and deploy applications quickly.

However, without central policy enforcement, teams may deploy resources that violate enterprise security standards.

Examples include:

Privileged containers
Containers running as root
Images from untrusted registries
Workloads without resource limits
Pods using host networking
Containers mounting sensitive host paths
Resources without ownership labels
Public LoadBalancer Services
Excessive Linux capabilities
Workloads without approved security controls

Security teams may document that these configurations are prohibited.

Documentation alone does not prevent them.

OPA Gatekeeper converts enterprise security requirements into enforceable Kubernetes policies.

It evaluates Kubernetes API requests and can reject configurations that violate approved standards.

Enterprise Security Requirement

↓

Gatekeeper Policy

↓

Kubernetes Admission Request

↓

Policy Evaluation

↓

Allow, Warn or Deny

Gatekeeper therefore creates a technical enforcement point between developer activity and the Kubernetes cluster.

What is Open Policy Agent?

Open Policy Agent, commonly called OPA, is a general-purpose policy engine.

OPA allows organisations to separate policy decisions from application and infrastructure code.

Instead of embedding security decisions directly inside every system, administrators define central policies that determine whether an action should be allowed.

OPA can be used for:

Kubernetes admission control
API authorisation
Infrastructure validation
CI/CD policy checks
Service-mesh authorisation
Application-level decisions
Cloud configuration validation
Compliance enforcement

OPA policies are written using the Rego policy language.

Policy Decision Model

OPA evaluates structured input against defined policy logic.

Structured Input

+

Policy Rules

+

Policy Data

↓

OPA Evaluation

↓

Decision

The decision may be:

Allow
Deny
Return a violation
Return supporting information
Require additional review

What is OPA Gatekeeper?

OPA Gatekeeper is a Kubernetes-native policy controller built using Open Policy Agent.

It integrates OPA with Kubernetes admission control and provides resources for:

Defining reusable policy templates
Applying policies to selected resources
Rejecting non-compliant requests
Auditing existing resources
Reporting policy violations
Managing policy parameters
Supporting policy testing
Applying selected resource mutations
Integrating external data into policy decisions

Gatekeeper extends Kubernetes using Custom Resource Definitions.

The primary validation resources are:

ConstraintTemplate
Constraint

Gatekeeper Architecture

Developer

↓

kubectl, Helm or CI/CD Pipeline

↓

Kubernetes API Server

↓

Authentication

↓

Authorisation

↓

Gatekeeper Admission Webhook

↓

OPA Policy Evaluation

↓

Allow or Deny

↓

Resource Stored in etcd

Gatekeeper operates during the admission stage.

It does not replace:

Kubernetes authentication
Kubernetes RBAC
Pod Security Admission
Network Policies
Runtime detection
Container image scanning

It complements these controls.

Kubernetes Request Lifecycle

A simplified Kubernetes request follows this sequence:

API Request

↓

Authentication

Who is making the request?

↓

Authorisation

What is the identity permitted to do?

↓

Admission Control

Does the requested configuration comply with policy?

↓

Resource Validation

↓

Resource Persisted

Gatekeeper works primarily in the admission-control stage.

Authentication, Authorisation and Admission

These controls answer different security questions.

Security Layer	Security Question	Example
Authentication	Who are you?	AWS IAM identity
Authorisation	What can you do?	Kubernetes RBAC
Admission Control	Is this configuration permitted?	Gatekeeper policy
Runtime Detection	What is the workload doing?	Falco alert

A user may be authorised to create Pods but should still be prevented from creating privileged Pods.

Developer Has Permission to Create Pods

↓

Developer Submits Privileged Pod

↓

RBAC Allows the Create Operation

↓

Gatekeeper Evaluates Pod Configuration

↓

Privileged Pod Denied

This demonstrates why RBAC alone is insufficient.

Gatekeeper Components

A typical Gatekeeper deployment includes several components.

Gatekeeper System

├── Admission Webhook
├── Audit Controller
├── ConstraintTemplates
├── Constraints
├── OPA Policy Engine
├── Custom Resource Definitions
├── Mutation Resources
└── Metrics Endpoint

Admission Webhook

The admission webhook evaluates new and updated Kubernetes resources.

It can inspect resources such as:

Pods
Deployments
StatefulSets
DaemonSets
Jobs
CronJobs
Services
Ingresses
Namespaces
Roles
RoleBindings
ClusterRoles
ClusterRoleBindings

When a request violates a Constraint, Gatekeeper can reject it.

Audit Controller

The audit controller evaluates resources that already exist in the cluster.

This is important because a resource may:

Have existed before a policy was created
Have been admitted while enforcement was disabled
Become non-compliant after a policy update
Exist in a namespace that was previously excluded
Have been created during a policy-engine outage

Existing Cluster Resources

↓

Gatekeeper Audit Controller

↓

Evaluate Against Constraints

↓

Record Violations

↓

Compliance Reporting

Admission enforcement prevents new violations.

Audit identifies existing violations.

ConstraintTemplates

A ConstraintTemplate defines reusable policy logic.

It normally specifies:

The name and type of the future Constraint
The schema for policy parameters
The target system
The policy logic
Violation messages

Think of a ConstraintTemplate as a reusable policy definition.

ConstraintTemplate

Defines:

- Policy Logic
- Expected Parameters
- Constraint Type
- Violation Output

A ConstraintTemplate does not normally determine the exact namespaces or workloads to which the rule applies.

That is configured through a Constraint.

Constraints

A Constraint activates a policy defined by a ConstraintTemplate.

It specifies:

Which resources are evaluated
Which namespaces are included
Which namespaces are excluded
What parameters are passed to the policy
Which enforcement action is used

ConstraintTemplate

Defines the reusable rule

↓

Constraint

Applies the rule to selected resources

ConstraintTemplate and Constraint Relationship

ConstraintTemplate

K8sRequiredLabels

↓

Constraint 1

Require owner label on Namespaces

↓

Constraint 2

Require owner label on Deployments

↓

Constraint 3

Require owner label in production

One template can support multiple Constraints with different parameters and scopes.

Example Policy Requirement

Consider the following enterprise requirement:

Every Kubernetes Namespace must contain an owner label.

This requirement can be implemented using:

A ConstraintTemplate that defines how required labels are evaluated.
A Constraint that requires the owner label on Namespace resources.

Example ConstraintTemplate

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels

      validation:
        openAPIV3Schema:
          type: object

          properties:
            labels:
              type: array

              items:
                type: string

  targets:
    - target: admission.k8s.gatekeeper.sh

      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          required_label := input.parameters.labels[_]
          not input.review.object.metadata.labels[required_label]

          msg := sprintf(
            "Resource must contain the required label: %v",
            [required_label]
          )
        }

This template creates a new Constraint type named:

K8sRequiredLabels

Understanding the ConstraintTemplate

The template contains several important sections.

Section	Purpose
`metadata.name`	Identifies the ConstraintTemplate
`crd.spec.names.kind`	Defines the new Constraint kind
`validation`	Defines accepted policy parameters
`targets`	Identifies the evaluation target
`rego`	Contains the policy logic
`violation`	Returns policy violations

Example Constraint

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: namespaces-must-have-owner
spec:
  enforcementAction: deny

  match:
    kinds:
      - apiGroups:
          - ""

        kinds:
          - Namespace

  parameters:
    labels:
      - owner

This Constraint applies the reusable label policy to Namespace resources.

Testing the Policy

Attempt to create a namespace without the required label.

apiVersion: v1
kind: Namespace
metadata:
  name: payment-production

Apply the manifest.

kubectl apply -f namespace.yaml

Expected result:

Error from server:

Admission webhook denied the request.

Resource must contain the required label: owner

Creating a Compliant Resource

Add the required label.

apiVersion: v1
kind: Namespace
metadata:
  name: payment-production

  labels:
    owner: payments-team

Apply the manifest again.

kubectl apply -f namespace.yaml

Expected result:

namespace/payment-production created

The resource is admitted because it complies with policy.

Rego Policy Language

Gatekeeper validation policies commonly use Rego.

Rego is a declarative policy language designed for evaluating structured data.

A Gatekeeper policy can access the submitted Kubernetes object through:

input.review.object

For example:

input.review.object.metadata.name

This retrieves the resource name.

input.review.object.metadata.namespace

This retrieves the namespace.

input.review.object.spec.containers

This retrieves the container list from a Pod.

Example Rego Logic

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.privileged == true

  msg := sprintf(
    "Privileged container %v is not permitted",
    [container.name]
  )
}

This rule:

Iterates through each container.
Checks whether privileged is set to true.
Returns a violation message.

Rego Evaluation Model

Rego describes conditions that must be true for a rule to produce a result.

Kubernetes Object Submitted

↓

Rego Reads Object Fields

↓

Policy Conditions Evaluated

↓

Violation Generated or No Violation

A violation result causes enforcement according to the Constraint configuration.

Matching Resources

Constraints use the match section to determine which resources are evaluated.

Policy scope may include:

Resource kinds
API groups
Namespaces
Namespace selectors
Object labels
Cluster-scoped resources
Namespaced resources

Matching Resource Kinds

Example:

match:
  kinds:
    - apiGroups:
        - apps

      kinds:
        - Deployment
        - StatefulSet

This policy applies only to Deployments and StatefulSets in the apps API group.

Matching Namespaces

match:
  namespaces:
    - production
    - payments

This applies the policy only to the listed namespaces.

Excluding Namespaces

match:
  excludedNamespaces:
    - kube-system
    - gatekeeper-system

Namespace exclusions should be used carefully.

Broad exclusions may create policy bypasses.

Namespace Selectors

A policy can target namespaces based on labels.

Example enterprise namespace labels:

metadata:
  labels:
    environment: production
    policy-tier: restricted

A Constraint can then target namespaces using a selector.

match:
  namespaceSelector:
    matchLabels:
      policy-tier: restricted

This enables scalable policy assignment.

Enforcement Actions

Gatekeeper Constraints can use enforcement actions to control policy behaviour.

Common actions include:

deny
warn
dryrun

Deny

spec:
  enforcementAction: deny

The request is rejected when it violates policy.

Use deny for mature and tested policies.

Examples include:

Privileged containers
Unapproved registries
Host filesystem access
Missing mandatory security settings

Warn

spec:
  enforcementAction: warn

The API request may continue, but the user receives a warning.

Warn mode is useful for:

Developer education
Policy rollout
Non-critical requirements
Upcoming enforcement changes

Dry Run

spec:
  enforcementAction: dryrun

The request is admitted, but violations are recorded through Gatekeeper audit.

Dry run is useful for:

Assessing potential impact
Discovering existing violations
Testing new policies
Planning remediation
Measuring policy readiness

Enforcement Rollout Strategy

Policy Designed

↓

Policy Tested Locally

↓

Dry-Run Mode

↓

Review Violations

↓

Remediate Workloads

↓

Warn Mode

↓

Notify Application Teams

↓

Deny Mode

↓

Continuous Monitoring

This staged approach reduces business disruption.

Deploying Gatekeeper

Gatekeeper can be installed using Helm.

Create or update the Helm repository.

helm repo add gatekeeper \
https://open-policy-agent.github.io/gatekeeper/charts

helm repo update

Install Gatekeeper.

helm install gatekeeper gatekeeper/gatekeeper \
--namespace gatekeeper-system \
--create-namespace

Verify the Installation

Check Gatekeeper Pods.

kubectl get pods -n gatekeeper-system

Expected components may include:

gatekeeper-audit

gatekeeper-controller-manager

Check deployments.

kubectl get deployments -n gatekeeper-system

Check services.

kubectl get services -n gatekeeper-system

Check Custom Resource Definitions.

kubectl get crds | grep gatekeeper

Enterprise Deployment Architecture

Amazon EKS Cluster

├── Gatekeeper Controller Replicas
├── Gatekeeper Audit Controller
├── Gatekeeper CRDs
├── ConstraintTemplates
├── Constraints
├── Prometheus Metrics
└── Central Policy Repository

Production deployments should use multiple controller replicas and suitable availability controls.

Example Policy — Deny Privileged Containers

The following conceptual template evaluates privileged containers.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sblockprivileged
spec:
  crd:
    spec:
      names:
        kind: K8sBlockPrivileged

  targets:
    - target: admission.k8s.gatekeeper.sh

      rego: |
        package k8sblockprivileged

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          container.securityContext.privileged == true

          msg := sprintf(
            "Privileged container %v is prohibited",
            [container.name]
          )
        }

Apply the corresponding Constraint.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockPrivileged
metadata:
  name: block-privileged-containers
spec:
  enforcementAction: deny

  match:
    kinds:
      - apiGroups:
          - ""

        kinds:
          - Pod

    excludedNamespaces:
      - kube-system
      - gatekeeper-system

Important Workload Coverage Consideration

Developers commonly create Deployments rather than individual Pods.

A Deployment creates Pods through a ReplicaSet.

Admission policies must be designed to evaluate the correct object structures.

Enterprise teams should test policies against:

Pods
Deployments
StatefulSets
DaemonSets
Jobs
CronJobs
ReplicaSets
Ephemeral containers

A policy that only checks direct Pod creation may not provide the intended coverage.

Example Policy — Require Resource Limits

Enterprise requirement:

Every application container must define CPU and memory limits.

Conceptual Constraint:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResources
metadata:
  name: containers-must-have-limits
spec:
  enforcementAction: dryrun

  match:
    kinds:
      - apiGroups:
          - apps

        kinds:
          - Deployment
          - StatefulSet
          - DaemonSet

  parameters:
    limits:
      - cpu
      - memory

The policy should initially run in dryrun mode to identify application impact.

Example Policy — Approved Registries

Enterprise requirement:

Production workloads may only use images from approved Amazon ECR registries.

Example approved registry:

123456789012.dkr.ecr.eu-west-2.amazonaws.com

Conceptual Constraint:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepositories
metadata:
  name: production-approved-registries
spec:
  enforcementAction: deny

  match:
    namespaceSelector:
      matchLabels:
        environment: production

    kinds:
      - apiGroups:
          - apps

        kinds:
          - Deployment
          - StatefulSet
          - DaemonSet

  parameters:
    repos:
      - 123456789012.dkr.ecr.eu-west-2.amazonaws.com/

This reduces the risk of deploying images from untrusted sources.

Example Policy — Restrict LoadBalancer Services

Enterprise requirement:

Only approved namespaces may create LoadBalancer Services.

A policy can inspect:

spec:
  type: LoadBalancer

Possible enforcement logic:

Service Type Is LoadBalancer

AND

Namespace Is Not Approved

↓

Deny Request

This helps prevent accidental public exposure.

Example Policy — Restrict HostPath

Enterprise requirement:

Application workloads must not mount worker-node file paths.

A policy can inspect Pod volumes for:

hostPath:
  path: /

Approved infrastructure components may require narrowly scoped exceptions.

Gatekeeper Policy Library

Organisations do not always need to create every policy from the beginning.

Gatekeeper policy libraries can provide reusable templates for common requirements such as:

Required labels
Allowed repositories
Container limits
Host namespace restrictions
Privileged container restrictions
Service type restrictions
Volume restrictions
Replica requirements
Ingress restrictions

Enterprise teams must still:

Review the policy logic
Test it
Approve it
Version it
Adapt it to internal standards
Monitor its effect

Using an existing template does not remove the need for governance.

Gatekeeper Audit

Gatekeeper audit periodically evaluates existing Kubernetes resources against configured Constraints.

Audit results can be viewed in Constraint status.

List Constraints.

kubectl get constraints

Inspect a specific Constraint.

kubectl describe \
k8srequiredlabels namespaces-must-have-owner

The status may include violations such as:

Resource kind
Resource name
Namespace
Violation message
Enforcement action

Example Audit Result

status:
  totalViolations: 2

  violations:
    - kind: Namespace
      name: legacy-application
      message: Resource must contain the required label owner

    - kind: Namespace
      name: temporary-test
      message: Resource must contain the required label owner

These resources may have existed before enforcement was enabled.

Admission Versus Audit

Capability	Admission	Audit
Evaluates new requests	Yes	No
Evaluates existing resources	No	Yes
Can block creation	Yes	No
Supports compliance discovery	Limited	Yes
Helps identify historical drift	No	Yes

Both capabilities are necessary for continuous governance.

Mutation

Gatekeeper also supports mutation capabilities through dedicated mutation resources.

Mutation can modify resources before admission.

Potential uses include:

Adding default labels
Adding annotations
Applying secure defaults
Setting approved configuration values
Assigning standard runtime classes

Incoming Resource

↓

Gatekeeper Mutation

↓

Resource Modified

↓

Validation Policies

↓

Resource Admitted

Mutation should be used carefully.

Developers should understand when their submitted resources are being changed.

Risks of Mutation

Mutation may introduce:

Unexpected application behaviour
Conflict with GitOps desired state
Difficulty troubleshooting manifests
Differences between submitted and stored resources
Policy-ordering complexity
Upgrade compatibility concerns

For security-critical settings, explicit configuration and validation may be easier to audit than silent mutation.

External Data

Some policy decisions require information that does not exist inside the Kubernetes resource.

Examples include:

Container vulnerability status
Image-signing status
Approved software inventory
External identity attributes
Risk classification
Registry reputation
Change-ticket approval

External-data integration can allow Gatekeeper policies to consult approved providers.

Kubernetes Admission Request

↓

Gatekeeper Policy

↓

External Data Provider

↓

Security or Compliance Decision

↓

Allow or Deny

External dependencies introduce availability and latency considerations.

External Data Risks

External policy decisions may be affected by:

Provider availability
Network latency
Stale data
Authentication failures
Provider compromise
Timeout behaviour
Caching behaviour

Enterprise designs must define what happens when an external provider is unavailable.

Failure Policy

The Kubernetes admission webhook configuration defines behaviour when the Gatekeeper webhook cannot respond.

Common strategies are:

Fail closed
Fail open

Fail Closed

Gatekeeper Unavailable

↓

Admission Request Rejected

Benefits:

Policy cannot be bypassed
Security remains enforced

Risks:

Deployments may stop
Emergency changes may be blocked
Cluster operations may be affected

Fail Open

Gatekeeper Unavailable

↓

Admission Request Allowed

Benefits:

Application deployments can continue
Availability impact is reduced

Risks:

Insecure resources may enter the cluster
Creates a temporary enforcement gap
Requires retrospective audit and remediation

Choosing Failure Behaviour

The decision should consider:

Policy criticality
Business-service availability
Cluster function
Emergency access requirements
Gatekeeper architecture
Monitoring capability
Recovery procedures
Regulatory obligations

A critical policy preventing privileged containers may warrant fail-closed behaviour.

A non-critical metadata policy may allow a different approach.

Gatekeeper Availability

Because Gatekeeper participates in the admission path, it must be operated as critical platform infrastructure.

Production controls should include:

Multiple controller replicas
Pod anti-affinity
PodDisruptionBudgets
Resource requests and limits
Health probes
Metrics collection
Alerting
Controlled certificate management
Tested upgrades
Tested failure scenarios
Documented recovery procedures

Enterprise Gatekeeper Architecture

Amazon EKS API Server

↓

Gatekeeper Validating Webhook Service

↓

Multiple Controller Replicas

↓

OPA Policy Evaluation

↓

ConstraintTemplates and Constraints

Meanwhile:

Gatekeeper Audit Controller

↓

Existing Kubernetes Resources

↓

Violation Reports

↓

Prometheus and SIEM

Policy Repository Architecture

Policies should be maintained in a controlled repository.

gatekeeper-policies/

├── templates/
│   ├── required-labels.yaml
│   ├── block-privileged.yaml
│   ├── allowed-registries.yaml
│   └── required-resources.yaml
│
├── constraints/
│   ├── development/
│   ├── testing/
│   └── production/
│
├── tests/
│   ├── compliant/
│   └── non-compliant/
│
├── exceptions/
├── documentation/
└── README.md

This separates reusable templates from environment-specific Constraints.

Policy Testing

Gatekeeper policies should be tested before they reach production.

Testing should cover:

Known compliant resources
Known non-compliant resources
Missing fields
Empty fields
Init containers
Ephemeral containers
Multiple containers
Namespaced resources
Cluster-scoped resources
Excluded namespaces
Helm-generated manifests
System workloads

Example Test Cases

Test	Expected Result
Non-root container	Pass
Root container	Deny
Approved ECR image	Pass
Public unapproved image	Deny
Workload with CPU and memory limits	Pass
Workload without limits	Violation
Approved system namespace	Excluded
Production namespace without label	Deny

Local Policy Testing

A local policy-testing workflow can evaluate policies before deployment.

ConstraintTemplate

+

Constraint

+

Test Kubernetes Manifest

↓

Local Policy Test

↓

Pass or Violation

Testing policies in CI/CD helps prevent broken policies from affecting cluster admission.

CI/CD Integration

Gatekeeper policy tests can be added to a policy pipeline.

Policy Pull Request

↓

YAML Validation

↓

Rego Validation

↓

Unit Tests

↓

Compliant Manifest Tests

↓

Non-Compliant Manifest Tests

↓

Security Review

↓

Merge and Deployment

Policies should be treated like production code.

GitOps Deployment

Gatekeeper policies can be distributed through GitOps.

Central Policy Repository

↓

Approved Pull Request

↓

GitOps Controller

↓

ConstraintTemplates

↓

Constraints

↓

Amazon EKS Clusters

Benefits include:

Version control
Repeatability
Multi-cluster consistency
Rollback
Audit history
Controlled promotion

Multi-Cluster Policy Management

Large organisations may operate hundreds of EKS clusters.

A multi-cluster model may use:

Enterprise Policy Library

↓

Environment Overlays

├── Development
├── Testing
├── Production
└── Regulated Production

↓

GitOps Deployment

↓

Multiple Amazon EKS Clusters

Core policies remain standardised, while Constraints may vary by risk tier.

Policy Tiers

An enterprise may define multiple policy tiers.

Tier	Environment	Example Enforcement
Tier 1	Sandbox	Warn and dry run
Tier 2	Development	Baseline enforcement
Tier 3	Production	Restricted enforcement
Tier 4	Regulated	Enhanced custom policies

This supports risk-based enforcement.

Gatekeeper and Pod Security Admission

Gatekeeper and Pod Security Admission can be used together.

Pod Security Admission

↓

Standard Kubernetes Workload Baseline

+

Gatekeeper

↓

Custom Enterprise Controls

Pod Security Admission can enforce:

Baseline Pod Security Standard
Restricted Pod Security Standard

Gatekeeper can enforce:

Approved registries
Resource limits
Ownership labels
Custom volume restrictions
Service exposure controls
Organisation-specific requirements

Gatekeeper and ValidatingAdmissionPolicy

Kubernetes also provides native validation through ValidatingAdmissionPolicy.

Native policies can reduce the need for an external webhook for some straightforward validation rules.

Gatekeeper may remain useful where organisations require:

Rego-based policy libraries
Existing Gatekeeper investments
Constraint-based parameterisation
Cross-cluster policy consistency
Gatekeeper audit reports
External data
Established compliance workflows
Complex policy logic

The two approaches should be evaluated based on organisational requirements rather than deployed without a clear strategy.

Gatekeeper and Runtime Security

Gatekeeper evaluates Kubernetes configuration.

It does not provide complete runtime threat detection.

For example, Gatekeeper may ensure that a container:

Runs as non-root
Drops Linux capabilities
Uses an approved image
Defines resource limits

After deployment, an attacker may still exploit an application vulnerability.

Runtime tools are needed to detect:

Interactive shells
Suspicious processes
Sensitive file access
Unexpected outbound connections
Privilege escalation attempts
Cryptomining behaviour

Gatekeeper

Prevents Misconfiguration

+

Falco

Detects Runtime Threats

+

Audit Logs

Records API Activity

↓

Comprehensive Kubernetes Security

Monitoring Gatekeeper

Gatekeeper should be monitored like any other critical security service.

Important operational signals include:

Controller availability
Audit-controller availability
Admission latency
Admission request failures
ConstraintTemplate errors
Constraint errors
Audit violations
Webhook certificate health
CPU and memory usage
Policy deployment failures
Rejected request volume

Prometheus Monitoring

Gatekeeper can expose metrics for Prometheus.

A monitoring workflow may follow:

Gatekeeper Metrics

↓

Prometheus

↓

Grafana

↓

Alertmanager

↓

Platform and Security Teams

Example Monitoring Metrics

An enterprise dashboard may track:

Metric Area	Purpose
Active constraints	Confirm expected policy coverage
Constraint errors	Identify broken policies
Admission duration	Detect performance degradation
Admission request count	Understand policy workload
Denied request count	Identify attempted violations
Audit violation count	Track existing non-compliance
Audit duration	Monitor audit performance
Controller replicas	Confirm availability

Security Monitoring Use Cases

Gatekeeper violations can identify:

Attempts to create privileged Pods
Attempts to use unapproved images
Attempts to expose public services
Attempts to mount host paths
Attempts to deploy without ownership
Repeated policy bypass behaviour
Misconfigured automated pipelines
Compromised deployment credentials

High-risk violations should be forwarded to the SIEM.

SIEM Integration Architecture

Gatekeeper Admission Events

↓

Kubernetes Audit Logs

↓

CloudWatch Logs or Log Forwarder

↓

Enterprise SIEM

↓

Correlation Rule

↓

SOC Alert

Example correlation:

Gatekeeper Denied Privileged Pod

+

Unusual IAM Role Assumption

+

Repeated API Requests

↓

Potential Privilege-Escalation Attempt

Enterprise Policy Dashboard

A Gatekeeper dashboard may display:

Violations by cluster
Violations by AWS account
Violations by namespace
Violations by policy
Denied requests
Dry-run findings
Repeated violation sources
Policies with errors
Excluded namespaces
Exception expiry
Gatekeeper availability
Policy coverage percentage

Policy Ownership

Every policy should have a defined owner.

Policy Type	Possible Owner
Container privilege	Cloud Security
Resource limits	Platform Engineering
Registry restrictions	Supply Chain Security
Required metadata	Cloud Governance
Public service exposure	Network Security
RBAC restrictions	Identity and Access Management
Compliance labels	Governance, Risk and Compliance

Ownership ensures violations and policy changes are handled correctly.

Policy Metadata

Each policy should document:

Policy name
Security objective
Risk addressed
Framework mapping
Owner
Enforcement level
Scope
Exceptions
Test cases
Review frequency
Version
Change history

Compliance Mapping

Gatekeeper policies can support requirements from:

CIS Kubernetes Benchmark
NSA Kubernetes Hardening Guidance
NIST controls
PCI DSS
ISO/IEC 27001
Internal cloud standards
Data-protection requirements

Example:

Enterprise Requirement	Gatekeeper Policy
Containers must not be privileged	Block privileged containers
Workloads must use trusted images	Approved registry policy
Resources require accountability	Required ownership labels
Production workloads require limits	Resource limits policy
Host access must be restricted	HostPath and host namespace policy

Gatekeeper provides enforcement evidence but does not automatically prove complete compliance.

Exception Management

Some workloads may require policy exceptions.

Examples include:

Security agents
Storage drivers
Networking components
Monitoring DaemonSets
Legacy applications
Emergency troubleshooting workloads

An exception must not become a broad bypass.

Exception Record

A policy exception should include:

Exception ID:

Policy:

Cluster:

Namespace:

Workload:

Business Justification:

Security Risk:

Compensating Controls:

Owner:

Approver:

Start Date:

Expiry Date:

Remediation Plan:

Safe Exception Design

Prefer narrow exceptions based on:

Exact namespace
Exact workload label
Exact resource kind
Exact service account
Exact time period

Avoid broad exceptions such as:

Exclude all system namespaces

Exclude all platform workloads

Exclude every resource owned by Team A

Broad exclusions significantly reduce policy effectiveness.

Common Gatekeeper Challenges

Rego Learning Curve

Rego may be unfamiliar to Kubernetes engineers.

Impact: Policies may be difficult to develop or review.

Response:

Start with approved policy libraries.
Provide Rego training.
Create reusable templates.
Require peer review.
Maintain automated tests.

Policy Breaks Applications

Strict policies may reject existing application configurations.

Impact: Deployment failures and business disruption.

Response:

Begin with dry-run mode.
Review audit violations.
Remediate workloads.
Enable enforcement gradually.

Incorrect Resource Coverage

A policy may inspect Pods but not controller templates.

Impact: Insecure workload controllers may bypass expected checks.

Response:

Test Deployments, StatefulSets, DaemonSets, Jobs and CronJobs.
Use tested templates.
Validate resource schemas.

Excessive Namespace Exclusions

Teams may request broad policy exclusions.

Impact: Security controls become ineffective.

Response:

Approve narrow exceptions.
Require expiry dates.
Apply compensating controls.
Monitor excluded workloads.

Admission Latency

Complex policies may slow Kubernetes API requests.

Impact: Deployment and cluster-operation delays.

Response:

Optimise Rego.
Reduce unnecessary policy scope.
Monitor admission latency.
Load-test policy changes.

Gatekeeper Availability

Webhook outages may block requests or permit bypasses.

Impact: Availability or security risk.

Response:

Use multiple replicas.
Configure disruption budgets.
Monitor health.
Test failure behaviour.

Policy Drift

Clusters may run different policy versions.

Impact: Inconsistent enterprise security.

Response:

Use GitOps.
Maintain a central policy repository.
Monitor deployed policy versions.
Automate drift detection.

False Positives

A policy may reject legitimate configurations.

Impact: Reduced developer trust and policy bypass pressure.

Response:

Improve test coverage.
Use representative application manifests.
Tune parameters.
Document policy rationale.

Enterprise Implementation Strategy

Phase 1 — Define Policy Objectives

Review enterprise security standards.
Map CIS, NSA and NIST requirements.
Identify high-risk Kubernetes configurations.
Define policy ownership.
Define exception governance.
Establish enforcement tiers.

Phase 2 — Deploy Gatekeeper

Install Gatekeeper on a non-production EKS cluster.
Validate controller health.
Configure multiple replicas.
Enable Prometheus monitoring.
Test admission behaviour.
Test audit functionality.

Phase 3 — Build the Initial Policy Library

Start with high-value policies:

Block privileged containers
Require non-root execution
Restrict hostPath volumes
Restrict host namespaces
Require resource limits
Require approved registries
Require ownership labels
Restrict LoadBalancer Services

Phase 4 — Test Policies

Create compliant test manifests.
Create non-compliant test manifests.
Test workload controllers.
Test namespaces and cluster-scoped resources.
Test system components.
Validate policy performance.
Conduct peer review.

Phase 5 — Run in Dry-Run Mode

Audit existing resources.
Measure violation volume.
Assign violations to owners.
Identify false positives.
Remediate applications.
Approve temporary exceptions.

Phase 6 — Enable Enforcement

Begin with critical production policies.
Use phased namespace rollout.
Monitor denied requests.
Validate deployment pipelines.
Maintain an emergency procedure.
Communicate policy changes.

Phase 7 — Scale Across the Enterprise

Store policies in Git.
Distribute policies using GitOps.
Define environment overlays.
Track policy versions.
Monitor cluster coverage.
Integrate violations with the SIEM.
Publish compliance dashboards.

Phase 8 — Operate Continuously

Review violations.
Test policy updates.
Monitor Gatekeeper availability.
Review exceptions.
Remove obsolete policies.
Reassess after Kubernetes upgrades.
Update framework mappings.
Conduct periodic policy effectiveness reviews.

Enterprise Best Practices

As a Cloud Security Engineer:

Use Gatekeeper as part of defence in depth.
Begin with a small set of high-value policies.
Use ConstraintTemplates for reusable policy logic.
Use Constraints for environment-specific enforcement.
Test policies against real application manifests.
Begin new policies in dry-run mode.
Remediate workloads before enabling denial.
Store policies and tests in Git.
Use peer review for Rego changes.
Deploy Gatekeeper with multiple replicas.
Monitor webhook availability and latency.
Monitor audit and admission violations.
Avoid broad namespace exclusions.
Require narrow and time-limited exceptions.
Integrate policy violations with SIEM workflows.
Apply Gatekeeper consistently across EKS clusters.
Combine Gatekeeper with Pod Security Admission.
Combine admission policy with runtime detection.
Review policy effectiveness after platform upgrades.
Treat Gatekeeper as critical production infrastructure.

Real-World Scenario

A global financial organisation operates more than 300 Amazon EKS clusters.

During an internal security assessment, the Cloud Security team identifies:

Privileged containers in production
Workloads using public container registries
Missing CPU and memory limits
Public LoadBalancer Services
Namespaces without ownership labels
HostPath mounts on application Pods
Inconsistent security controls across clusters

The organisation deploys OPA Gatekeeper as its central Kubernetes policy engine.

The implementation follows a phased strategy.

First, the security team creates ConstraintTemplates for:

Privileged container restrictions
Approved image repositories
Required resource limits
Required ownership labels
Restricted Service types
Restricted host volumes

The team deploys corresponding Constraints using dryrun.

Gatekeeper audit identifies hundreds of existing violations without blocking application deployments.

The findings are assigned to application owners and tracked through remediation tickets.

After the highest-risk violations are resolved, the organisation enables deny enforcement for production clusters.

Policies are stored in Git, tested through CI/CD and distributed using GitOps.

Gatekeeper metrics are collected by Prometheus, policy dashboards are displayed in Grafana and high-risk admission violations are forwarded to the SIEM.

The result is a measurable and consistently enforced Kubernetes security baseline across the enterprise.

Key Takeaways

OPA is a general-purpose policy engine that uses Rego.
Gatekeeper integrates OPA with Kubernetes admission control.
ConstraintTemplates define reusable policy logic.
Constraints apply that logic to selected Kubernetes resources.
Admission enforcement prevents new non-compliant resources.
Gatekeeper audit identifies violations in existing resources.
Dry-run mode supports safe policy assessment and rollout.
Policies must be tested against Pods and workload controllers.
Gatekeeper should be deployed as highly available infrastructure.
Policy violations should be monitored and integrated with enterprise security operations.
Exceptions should be narrow, approved and time-limited.
Gatekeeper complements Pod Security Admission, RBAC, Network Policies and runtime detection.
Enterprise success requires policy ownership, version control, testing and continuous governance.

Knowledge Check

1. What is the primary purpose of OPA Gatekeeper?

Answer: To enforce policy-as-code against Kubernetes resources during admission and audit existing resources for compliance violations.

2. What is the difference between a ConstraintTemplate and a Constraint?

Answer: A ConstraintTemplate defines reusable policy logic and parameters, while a Constraint applies that policy to selected resources with a specific scope and enforcement action.

3. Why should new Gatekeeper policies begin in dry-run mode?

Answer: Dry-run mode identifies existing violations and potential application impact without blocking deployments.

4. What is the purpose of the Gatekeeper audit controller?

Answer: It evaluates existing Kubernetes resources against configured Constraints and reports resources that violate policy.

5. Why must Gatekeeper be designed for high availability?

Answer: Gatekeeper participates in the Kubernetes admission request path, so an outage may block API operations or create a policy-enforcement gap depending on the configured failure behaviour.

What’s Next?

In the next lesson, we will examine Kyverno, a Kubernetes-native policy engine that uses YAML-based policies to validate, mutate, generate and verify Kubernetes resources and container images.

➡️ Next Lesson: Lesson 07 — Kyverno