Kubernetes Control Center

The Kubernetes Control Center is EnforceAuth's console for operating OPA or EOPA Policy Decision Point (PDP) fleets that run in or alongside Kubernetes — and tracking them in PDP Monitoring.

It is not a Kubernetes product that replaces the API server or cluster RBAC. It is the fleet operations layer for your PDPs: bundle health, decision flow, and deployment correlation.

Console surface	Route	What you see
Dashboard — PDP Fleet Health	/dashboard	Healthy / degraded / unhealthy summary
PDP Monitoring	/monitoring	Per-instance trends, bundle issues, status volume

Those views answer: Are my OPA instances up? Did they activate the latest bundle? Are decisions flowing? — regardless of which Kubernetes pattern below you use.

Two OPA patterns on Kubernetes — pick the right problem

OPA meets Kubernetes in two distinct ways. EnforceAuth supports both as a control plane (Git → bundle → deploy → audit), but the PEP, Rego input, and who feels the deny are different.

	Application authorization (sidecar)	Cluster admission / platform governance
What is gated	API requests inside your app (who can do what)	Kubernetes resources at create/update time (Pod, Deployment, Ingress, …)
PEP	Your application code	Kubernetes API server (ValidatingAdmissionWebhook) or OPA Gatekeeper
PDP placement	OPA sidecar in the app pod (localhost:8181)	OPA Deployment or Gatekeeper controller — called by the apiserver
Typical Rego	data.authz.allow with app input	data.kubernetes.admission (or Gatekeeper constraints) with AdmissionReview
Deny feels like	HTTP 403 from your service	kubectl apply rejected; CI/CD pipeline failure
EnforceAuth KCC guide	Pattern A below — primary	Pattern B below

Do not conflate the two

Sidecar OPA does not gate cluster setup by itself. Admission OPA does not authorize in-app API calls unless you also wire a PEP. Many enterprises run both — separate policy repos or packages, separate PDP fleets, same EnforceAuth tenant.

Pick OSS OPA or EOPA before you deploy either pattern: OPA vs EOPA.

---

Pattern A: Application authorization (sidecars)

The most common EnforceAuth pattern: one OPA/EOPA container per application pod. The app (PEP) calls OPA on loopback; OPA evaluates Rego and returns allow/deny.

┌─────────────────────────────────────────────────────────────────┐
│ Kubernetes cluster                                              │
│  ┌──────────────────────────────────────┐                       │
│  │ Pod                                   │                       │
│  │  App (PEP) ──localhost──► OPA sidecar │  ◄── PDP: evaluate   │
│  │                           (PDP)       │      app authz Rego  │
│  └──────────────────┬───────────────────┘                       │
└─────────────────────┼───────────────────────────────────────────┘
                      │ bundle poll + decision_logs + status
                      ▼
              ┌───────────────┐
              │ EnforceAuth   │  ◄── Control plane: Git → bundle
              └───────────────┘

Layer	Responsibility
App (PEP)	Build input, call PDP, enforce allow/deny on the request
OPA / EOPA (PDP)	Evaluate Rego; same bundle format EnforceAuth publishes
EnforceAuth	Author, test, deploy bundles; ingest logs and fleet status
Kubernetes	Orchestrates pods only — not the authorization decision

Deep dive on sidecar vs daemon vs centralized: Deployment patterns § Sidecar.

Why sidecars + EnforceAuth

Value	How it works
Per-service isolation	Bad bundle rollout affects one pod replica
Low latency	PEP → 127.0.0.1:8181
Git-native lifecycle	EnforceAuth deploy → PDPs poll automatically
Fleet visibility	status → PDP Monitoring
Audit	decision_logs → Decisions and policy coverage

Sidecar setup (summary)

1. Entity + policy source + bundle destination — Quickstart
2. API key with decisions:write and status:write — API keys
3. PDP config.yaml — bundles + decision_logs + status — PDP integration
4. Sidecar Deployment — app + OPA containers in the same pod
5. PEP wiring — Application integration

Illustrative sidecar excerpt:

containers:
  - name: app
    env:
      - name: OPA_URL
        value: http://127.0.0.1:8181
  - name: opa
    image: openpolicyagent/opa:latest
    args: ["run", "--server", "--addr=0.0.0.0:8181", "--config-file=/config/config.yaml"]

Only the sidecar needs egress to object storage and api.enforceauth.com / api.enforceauth.dev.

Sidecar config.yaml and Deployment

Use View Config on the API key, then extend for bundles + fleet identity:

services:
  enforceauth:
    url: ${ENFORCEAUTH_URL}/v1
    headers:
      X-API-Key: ${ENFORCEAUTH_API_KEY}
  enforceauth-bundle:
    url: https://YOUR_BUCKET.s3.YOUR_REGION.amazonaws.com
    credentials:
      s3_signing:
        environment_credentials: {}

bundles:
  authz:
    service: enforceauth-bundle
    resource: policies/bundle.tar.gz
    polling:
      min_delay_seconds: 60
      max_delay_seconds: 120

decision_logs:
  service: enforceauth
  reporting:
    min_delay_seconds: 30
    max_delay_seconds: 60

status:
  service: enforceauth

labels:
  id: ${OPA_INSTANCE_ID}
  instance_name: ${OPA_INSTANCE_NAME}
  environment: production

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
spec:
  template:
    spec:
      volumes:
        - name: opa-config
          secret:
            secretName: enforceauth-opa-config
      containers:
        - name: app
          image: your-app:latest
          env:
            - name: OPA_URL
              value: http://127.0.0.1:8181
        - name: opa
          image: openpolicyagent/opa:latest
          args:
            - run
            - --server
            - --addr=0.0.0.0:8181
            - --config-file=/config/config.yaml
          volumeMounts:
            - name: opa-config
              mountPath: /config
          env:
            - name: ENFORCEAUTH_URL
              valueFrom:
                secretKeyRef:
                  name: enforceauth-pdp
                  key: api-url
            - name: ENFORCEAUTH_API_KEY
              valueFrom:
                secretKeyRef:
                  name: enforceauth-pdp
                  key: api-key
            - name: OPA_INSTANCE_ID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: OPA_INSTANCE_NAME
              value: payments-api
          readinessProbe:
            httpGet:
              path: /health
              port: 8181

Generate traffic after deploy — without evaluations, Decisions stay empty even when fleet health is green.

---

Pattern B: Cluster admission and platform governance

Use this pattern when you need to gate how Kubernetes itself is configured — before workloads run.

Examples: block privileged containers, require labels, enforce resource limits, deny latest image tags, restrict namespaces, validate Ingress hosts.

kubectl / Helm / CI
        │
        ▼
Kubernetes API server ──ValidatingWebhook──► OPA (PDP)
        │                                         │
        │ allow → resource admitted               │ bundle poll
        │ deny  → apply fails                     ▼
        │                                   EnforceAuth
        ▼
   etcd (desired state)

Layer	Responsibility
Kubernetes API server (PEP)	Sends AdmissionReview to webhook on create/update
OPA / EOPA (PDP)	Evaluates Rego; returns allow/deny (and optional patch)
EnforceAuth	Same control plane — Git policies, bundle deploy, Decisions, PDP Monitoring
Your app sidecar	Not involved — this is infrastructure policy, not app authz

Gatekeeper vs raw admission webhook

Approach	When to use
OPA Gatekeeper	CNCF-friendly constraint framework; ConstraintTemplate + Constraint CRDs; OPA runs inside Gatekeeper
OPA admission webhook	Direct ValidatingWebhookConfiguration → OPA HTTP API; maximum flexibility, you own the wiring

Both are PDP fleets EnforceAuth can feed with the same bundle.tar.gz pipeline. Decision logs often use paths like kubernetes/admission/pods — visible in Decisions like any other evaluation.

Official OPA Kubernetes admission docs: openpolicyagent.org/docs/kubernetes.

EnforceAuth setup for admission fleets

The control plane steps are the same as sidecars:

1. Rego in Git (admission packages — different input shape than app authz)
2. EnforceAuth deploy → bundle on S3/GCS/Azure
3. OPA admission Deployment polls bundle; decision_logs + status use the same API keys
4. PDP Monitoring shows admission OPA instances — use labels.instance_name such as k8s-admission-prod or gatekeeper-us-east

# OPA config.yaml — same EnforceAuth plugins as sidecars
labels:
  instance_name: k8s-admission-prod
  cluster: prod-us-east-1

Separate entity or repo? Platform teams often use a dedicated EnforceAuth system entity for cluster policy vs application authorization — clearer promotion chains and fleet views.

Two fleets, one console

Kubernetes Control Center (PDP Monitoring) is pattern-agnostic. Sidecar PDPs and admission PDPs both report status and decision_logs — filter by instance_name / labels to separate app authz from platform policy.

---

Instance identity in fleet views

EnforceAuth keys each PDP by pdp_instance_id from the status payload:

Label	Use
labels.instance_name	Preferred — e.g. payments-api, k8s-admission-prod, gatekeeper-us-east
labels.id	Fallback — pod name for per-replica identity

EOPA fleets

EOPA may regenerate labels.id on restart. Set labels.instance_name so PDP Monitoring does not show phantom instances after rollouts.

Use labels.environment and custom labels (e.g. cluster) to match EnforceAuth environments and separate admission vs app fleets.

---

Track your fleet in EnforceAuth

Dashboard — PDP Fleet Health

console.enforceauth.com/dashboard — fleet summary and link to PDP Monitoring.

Fleet status is tenant-wide — appropriate when one platform team operates every OPA instance (sidecar, admission, or both).

PDP Monitoring

/monitoring — summary cards, health trends, status volume, Recent Issues (bundle/plugin errors).

A pod or Gatekeeper controller can be Ready in Kubernetes while OPA is Unhealthy (stale bundle). Use EnforceAuth fleet views after every deployment.

Decisions and policy coverage

Console	Route	Applies to
Decisions	/decisions	App authz + admission evaluations
Policies	/policies	Coverage — which rules fired
Deployments	/deployments	Bundle revision correlation

---

Day-2 operations

Ship new policy

1. Merge Rego to Git (or GitHub Actions deploy)
2. Confirm deployment Success
3. Wait for PDP poll (or rolling restart admission Deployment / sidecars)
4. Watch PDP Monitoring and Decisions

Scale the fleet

Each new PDP replica with a distinct identity appears in monitoring. Stagger bundle polling — Deployment patterns § fleet scale.

When something breaks

Symptom	Where to look
Fleet empty	Missing status:write; egress blocked
Unhealthy after deploy	Bundle path, IAM — Integrations troubleshooting
Healthy but no decisions	Missing decisions:write; no traffic (app) or no admission traffic (platform)
kubectl apply denied but Monitoring green	Admission uses a different PDP fleet — check that instance's decisions

---

What EnforceAuth does not do in Kubernetes

• Does not inject sidecars or webhooks — you own manifests, Helm, or Gatekeeper install
• Does not replace Kubernetes RBAC — RBAC controls who can call the API; OPA admission adds policy on top
• Does not merge app authz and admission — same platform, typically separate policy packages and PDP fleets

For ingress-only application authz (no sidecar), see Gateway / mesh.

---

MCP gateway fleets

A third PDP-on-Kubernetes pattern: the MCP Authorization Gateway — OPA behind an MCP authorization gateway. Same EnforceAuth bundle + PDP Monitoring model; the PEP is the gateway Keep component (not the app or apiserver). EnforceAuth documents this pattern using PortcullisMCP as the reference baseline.

→ MCP gateway on Kubernetes and Deployment patterns.

---

Related guides

• Deployment patterns — sidecar, admission, daemon, centralized
• OPA vs EOPA
• PDP integration
• Application integration — Pattern A PEP
• API keys
• 15-minute quickstart