15-Minute Quickstart

Get from zero to a successful deployment, a live bundle at your destination, and at least one decision log in the console.

Step 0 — Choose your PDP (OPA or EOPA)

Do this before you configure Git or S3 — even if you are brand new to Policy as Code.

Default: OSS OPA

Most first-time teams start with OSS OPA (openpolicyagent/opa). Choose EOPA only when you have a concrete requirement: decision log masking at the PDP, delta bundles at very large scale, or bundle partitioning.

Choose OSS OPA	Choose EOPA
Greenfield / first Policy as Code project	Decision logs must be masked before leaving your network
Standard RBAC/ABAC workloads	Hundreds+ of PDPs with large, frequently updated bundles
Simplest docs and community examples	Bundle partitioning across fleet segments
(Also: migrating from embedded if checks — still start with OSS OPA)	(Also: existing Styra DAS™ / EOPA fleet — see migration guide)

→ Full decision guide: OPA vs EOPA · Getting Started with OPA · Deployment patterns

Already decided? Continue below. Not sure about the broader architecture? Read Your Policy as Code journey first.

Prerequisites

• EnforceAuth account — console.enforceauth.com (or console.enforceauth.dev)
• A Git repository with Rego policies (minimum: one package and an allow rule), or use EACommerce
• For bundle output: an S3, GCS, or Azure Blob bucket EnforceAuth can write to
• For PDP telemetry: ability to add an API key to your OPA/EOPA config

Choose your starting path

Option A — You already run OPA (or EOPA)

Keep your Rego and PEP code. EnforceAuth becomes the control plane for build, promotion, and audit.

Step	What you do	Detail
A1	Create org + system	Step 1
A2	Connect Git policy source	Step 2
A3	Configure bundle destination	Step 3
A4	Deploy (manual or CI)	Step 4
A5	Point PDP at new bundle	Step 5
A6	Wire PEP + send traffic	Step 6
A7	Confirm decision logs	Step 7

Option B — Start from EACommerce (no app yet)

Fastest end-to-end demo with a pre-built PEP + policies.

Step	What you do	Detail
B1	Clone EACommerce	Option B setup
B2	Create org + system in console	Step 1
B3	Connect EACommerce policy repo	Step 2
B4–B7	Same as Option A	Steps 3–7

---

Step 1 — Create organization and system

EnforceAuth models your estate as an entity tree. Policies deploy to systems; orgs group them.

1. Sign in to the console.
2. Open System Settings → Entity Management (/system-settings/entities).
3. Click Create Entity.
4. Create an Organization — e.g. Acme Corp. This is your tenant-scoped root.
5. Open the new org → Create Child → choose System — e.g. Payments API.
6. The system is where you attach policy source, bundle destination, and environments.

Tip: Put shared Git and storage config on the org so child systems inherit it. See Entity model.

Verify: System appears under the org in the entity tree with type System.

---

Step 2 — Connect Git policy source

Tell EnforceAuth where Rego lives. Full reference: Policy sources.

2a — Connect GitHub (recommended for private repos)

1. System Settings → Integrations (/system-settings/integrations)
2. Connect GitHub → authorize the EnforceAuth GitHub App on your org/repo

2b — Or use a Personal Access Token

1. System Settings → Secrets (/system-settings/secrets or entity Secrets tab)
2. Create a Generic Secret with a GitHub PAT:
   • Contents — Read (Read/Write if you use console PR-based edits)
   • Pull requests — Read (Read/Write if needed)
   • Metadata — default (read-only)

2c — Configure policy source on the system

1. Open your system entity → Configuration tab
2. Policy Source card → Edit
3. Set:

Field	Example
Storage Type	Git
Service	GitHub
Repository URL	https://github.com/your-org/policies
Branch	main
Policy Path	policies/
Credentials Secret	Your PAT secret (skip if GitHub App covers this repo)

4. Click Test Connection — must succeed before save
5. Save

If Test Connection fails, see GitHub and storage integration troubleshooting before opening a deploy.

2d — Add a minimal Rego policy (if starting fresh)

In your repo under policies/:

package authz

default allow := false

allow if {
    input.user.roles[_] == "admin"
}

Add policies/authz_test.rego and run opa test . locally. See Testing policies.

Verify: After a deploy (Step 4), files appear on the Policies tab for this system.

---

Step 3 — Configure bundle destination

EnforceAuth writes bundle.tar.gz here after a successful deploy. PDPs pull from this location. Full reference: Bundle destinations.

3a — Prepare object storage

Amazon S3 example — create a bucket and IAM permissions:

Principal	Permissions
EnforceAuth (deploy role)	s3:PutObject, s3:DeleteObject on bundle path
OPA/EOPA PDP	s3:GetObject, s3:ListBucket on bucket/path

3b — Store cloud credentials

1. Secrets → create AWS S3 Credentials (or GCS / Azure equivalent)
2. Scope the secret to the org or system entity

3c — Configure destination on the system

1. System entity → Configuration → Bundle Destination → Edit
2. Set:

Field	Example
Output Type	S3
Bucket Name	acme-authz-bundles
Region	us-east-1
Bundle Path	payments/bundle.tar.gz
Credentials Secret	Your AWS secret

3. Test Connection → Save

If bundle verification fails (common: S3 AccessDenied or wrong region), use the integrations troubleshooting guide.

3d — Configure environments (optional but recommended)

Still on Configuration → Environments:

Environment	Branch	Bundle path override	Promotes to
dev	main	payments/dev/bundle.tar.gz	staging
staging	release/*	payments/staging/bundle.tar.gz	production
production	main	payments/prod/bundle.tar.gz	—

See Multi-environment best practices.

Verify: Entity shows as deployable (has effective policy source + bundle destination).

---

Step 4 — Deploy policies

Trigger the pipeline: clone → opa test → build bundle → upload. Full reference: Deployments.

4a — Manual deploy (fastest first time)

1. Open Deployments (/deployments)
2. Click Deploy
3. Select your system entity
4. Choose Environment (e.g. dev)
5. Initiate Deployment
6. Open the run → watch phases through Complete

4b — GitHub Actions (recommended for ongoing use)

1. Create a trust policy on the system (CI/CD Tokens tab)
2. Add workflow using deploy-action:

name: Deploy Policies
on:
  push:
    branches: [main]
    paths: ['policies/**']
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: EnforceAuth/deploy-action@v1
        with:
          entity-id: ${{ vars.ENFORCEAUTH_ENTITY_ID }}
          environment: dev

Full guide: GitHub Actions and CI/CD.

Verify:

• Run status Success
• Object exists at bundle path in S3/GCS/Azure
• Policies tab shows ACTIVE status for deployed rules

---

Step 5 — Configure your PDP

Your Policy Decision Point pulls the bundle and reports decision logs. Pick a deployment pattern first: Deployment patterns (sidecar vs host agent vs centralized).

5a — Create an API key

1. Open your system entity → API Keys tab
2. Create API Key
3. Name: e.g. payments-opa-dev
4. Scopes: Write Decisions (decisions:write); add Write Status (status:write) for fleet health
5. Copy the key — shown once
6. Click View Config for the PDP YAML template

Full reference: API keys.

5b — Configure bundle polling + decision logs

Merge bundle service config with telemetry (see PDP integration):

services:
  enforceauth-bundle:
    url: https://YOUR_BUCKET.s3.YOUR_REGION.amazonaws.com
    credentials:
      s3_signing:
        environment_credentials: {}

  enforceauth:
    url: ${ENFORCEAUTH_URL}/v1
    headers:
      X-API-Key: ${ENFORCEAUTH_API_KEY}

bundles:
  authz:
    service: enforceauth-bundle
    resource: payments/dev/bundle.tar.gz
    polling:
      min_delay_seconds: 10
      max_delay_seconds: 20

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

Environment variables:

Variable	Value
ENFORCEAUTH_URL	https://api.enforceauth.com or https://api.enforceauth.dev
ENFORCEAUTH_API_KEY	Key from step 5a

See Bundle polling behavior for poll intervals, stale-bundle behavior, and what happens when object storage or the EnforceAuth API is unreachable.

Sidecar: mount this as config.yaml in your OPA/EOPA container. Host agent: /etc/opa/config.yaml. EOPA: same file, EOPA build — see PDP integration § EOPA.

Verify: curl localhost:8181/health returns OK; curl localhost:8181/v1/status shows bundle activation; revision matches latest deploy.

---

Step 6 — Wire your application (PEP)

Your app sends input JSON to the PDP and enforces allow/deny. Full reference: Application integration.

6a — Example input

{
  "user": { "id": "u-1", "roles": ["admin"] },
  "action": "read",
  "resource": { "type": "account", "id": "acct-99" }
}

6b — Query OPA

curl -s -X POST http://127.0.0.1:8181/v1/data/authz/allow \
  -H "Content-Type: application/json" \
  -d '{"input": {"user": {"roles": ["admin"]}, "action": "read", "resource": {"type": "account"}}}'

Expect "result": true for allowed requests.

6c — Enforce in middleware

Deny the HTTP request (403) when result is not true. Fail closed on PDP errors unless you have explicit risk acceptance.

Send real traffic through the PEP — decision logs only appear when OPA evaluates live requests.

---

Step 7 — Verify decision logs

1. Open Decisions (/decisions) in the console
2. Filter by your system entity
3. Confirm entries show:
   • Allow/deny outcome
   • input payload
   • Bundle version matching Step 4 deploy
4. On Policies, coverage moves from Never evaluated to Evaluated for rules that fired

Full reference: Decision logs.

Success checklist:

• Deployment Success with expected Git commit
• Bundle object at configured path
• PDP pulling current bundle revision
• At least one decision log entry
• Policy coverage updated

---

Option B — EACommerce end-to-end

EACommerce is a sample e-commerce app with PEP, OPA sidecar, and example policies.

git clone https://github.com/EnforceAuth/ea-commerce.git
cd ea-commerce

1. Follow the EACommerce README for local Docker Compose (app + OPA sidecar)
2. Complete Steps 1–4 in the console using the EACommerce policy repo URL
3. After deploy, set EACommerce env vars:
   • ENFORCEAUTH_URL — your API host
   • ENFORCEAUTH_API_KEY — from Step 5a
   • Bundle URL / path — match your bundle destination
4. Restart the stack and trigger sample API calls from the README
5. Confirm decisions in the console (Step 7)

---

What's next

Topic	Guide
Architecture choices	Policy as Code journey
Sidecar vs agent vs centralized	Deployment patterns
Rego patterns	Rego patterns
CI/CD automation	GitHub Actions
Find embedded auth to extract	Zift
Govern AI agent MCP tool calls	MCP Authorization Gateway
Platform tour	EnforceAuth getting started
API	API Reference