Policies as code and GitOps
Authorization policies on SecureAuth Connect can be managed through a GitOps workflow: the Git repository is the source of truth, changes are reviewed as pull requests, and the platform is reconciled to match the repository. This page walks through the workflow and the SecureAuth features that support each stage.
GitOps workflow
The GitOps workflow has six stages:
Each stage maps to a specific SecureAuth capability described below.
1. Author
Policies can be authored in either surface:
- The visual policy editor, which assembles validators into a logical structure.
- Rego (Open Policy Agent language), which is a better fit when policies need to live as code in a repository.
For GitOps workflows, Rego is usually the cleaner choice: the policy is a plain text file that fits naturally into a pull request. Visual editor policies can also be exported through declarative configuration, so they too can be managed in Git if you prefer that authoring surface.
2. Commit
Store policy definitions and SecureAuth configuration in a Git repository. A typical layout:
- A
policies/directory with one Rego file per policy. - A
config/directory with declarative configuration for workspaces, scopes, clients, and policy attachments. - A
tests/directory with sample inputs and expected outcomes used by CI.
Branch, commit, and tag policy changes the same way you manage application code.
3. Review
Pull requests become the review surface for policy changes. A reviewer can see:
- The policy diff.
- Which attachment points are affected, by reading the declarative configuration diff.
- The CI test results for the new policy version.
Policy reviews stay inside the tooling developers already use, and sensitive changes can require additional approvals through standard Git providers.
4. Test
SecureAuth includes policy testing and simulation for exactly this stage. Three testing surfaces are available:
- Visual editor test mode for policies authored visually.
- Sample-input evaluation for Rego policies through the embedded editor or the CLI.
- The policies API for driving tests from a CI pipeline. See the policies API reference.
A test run covers the inputs that matter: representative user claims, edge cases, and the attribute values where the policy makes its decision. CI fails the build if any test fails, so a broken policy never reaches a tenant.
5. Apply
Once a change is merged, declarative configuration import applies it to the target tenant. The import is idempotent and reconciles the live configuration to match the repository state.
A common pipeline:
- Dev tenant. Apply on every merge to a development branch.
- Staging tenant. Apply on every merge to the main branch.
- Production tenant. Apply on a tagged release with a manual approval gate.
Because the import is declarative, rolling back a policy change is the same operation in reverse: revert the commit and re-run the import.
6. Audit
Once policies are live, decision logs record every allow, deny, and policy change. You can:
- Verify a policy change is having the effect the PR promised.
- Catch regressions by comparing decision patterns before and after a release.
- Explain specific outcomes back to the teams who requested the change.
What lives in Git
A practical split:
| Artifact | In Git | Source of truth |
|---|---|---|
| Rego policy files | Yes | Git |
| Visual editor policy definitions (exported) | Yes | Git |
| Policy attachments (workspace, app, scope, API) | Yes | Git |
| Scopes, clients, workspaces | Yes | Git |
| Identity data (users, relationships) | No | Identity pool / permission system |
| Decision logs | No | Audit log store |
Identity data and decision logs are runtime state. They flow through the platform's own stores, not through the configuration pipeline.
When to skip GitOps
GitOps is the right default for most teams, but there are cases where direct UI authoring is the better path:
- Early exploration while the policy model is still in flux.
- One-off emergency fixes when a faster cycle than a PR review is warranted. In that case, reconcile the change back into Git after the incident.
- Non-technical authors configuring visual editor policies for a narrow domain. Those authors can still publish directly and export to Git later.
The pipeline should be the default, not the only path.