Policy that can’t quietly stop being true
Cluster policy administered from Git and reconciled continuously, so what you declared and what is actually enforcing are the same thing. Audit before you enforce. Revert with a revert.
Nobody knows which policies are live
Policy engines are a solved problem. Policy administration is not.
“Which policies are enforcing in staging but not production?”
Or the reverse, which is worse and more common.
“Who applied that constraint, and when, and why?”
The cluster knows what is installed. It does not know the reasoning.
“What would break if I turned this one on?”
The usual way to find out is to turn it on.
“Is this policy still doing anything?”
A policy that has denied nothing in six months is either working perfectly or not running.
Each of these is answerable. None of them is answerable by the engine alone, because the engine only knows what is installed right now — not what you intended, or what changed, or what it cost you.
Argo CD’s idea, narrowed until it’s sharp
A general GitOps engine can tell you a policy is synced. Only a policy-specific one can tell you what it’s denying.
01
Declare in Git
Policies live in a repository as ordinary Rego plus a small amount of Sampleless configuration saying where they apply and how hard.
02
Reconcile continuously
The operator watches the repository and the cluster, and closes the gap between them. A hand-edited constraint is reverted, and the drift is reported rather than silently corrected.
03
Audit against real traffic
A new policy reports what it would have denied, on live admission requests, without denying anything. You get the blast radius before you take it.
04
Promote as a diff
Moving from audit to enforce is a change in Git, reviewed like any other. Rolling it back is a revert, and it takes effect as fast as the reconcile loop.
Built to be operated, not just installed
Audit before enforce
Every policy has a dry-run mode that evaluates real admission traffic and reports what it would have rejected. Promotion is deliberate, and the list of things you are about to break is available before you break them.
Drift detection, not just correction
When the cluster and the repository disagree, the reconciler fixes it and tells you it happened. A policy someone disabled by hand at 2am becomes a reported event rather than a silent gap.
A policy library, not a blank file
Common constraints ship as parameterized policies you reference rather than author, the same way our CI ships reusable steps. Custom policy is ordinary Rego and stays portable to any OPA.
Scoped by namespace and cluster
The same policy set applies differently across environments by declaration, so staging enforcing less than production is a stated intention rather than an accident nobody noticed.
Enforcement for platform RBAC
Sampleless RBAC decides who may act; Driftless enforces the conditions at admission. Registry publish rules, pipeline permissions, and workload constraints are all the same kind of object.
Decisions are telemetry
Every allow and deny is a signal, collected at full fidelity like everything else on the platform. Policy stops being a black box the moment you can query what it did.
Built for the way policy actually gets adopted
Nobody turns on cluster-wide enforcement in one step. The product is shaped around the path teams actually take.
GitOps reconciliation and audit mode
The core loop: policies from Git, continuous reconciliation, drift reporting, and dry-run evaluation against live admission traffic.
Platform-wide Sampleless RBAC
One identity and permission model spanning every Sampleless product, so who may publish a package, trigger a pipeline, or query telemetry is answered in one place rather than five.
Policy library
Parameterized constraints for the cases every cluster needs, referenced rather than authored.
Multi-cluster policy fleets
One declared policy set applied across a fleet with per-cluster scoping, and a single view of what is actually enforcing where.
Bring us the policy you have been afraid to turn on. We will show you what it would reject.
Frequently asked questions
- What stops a bad policy from taking down my cluster?
- Nothing enforces until you say so. Every policy runs against real traffic first and reports what it would have rejected, so you see the list of things you are about to break before you break them. Turning it on is a merge. Turning it off is a revert.
- How is this different from Kyverno or Gatekeeper?
- Those are policy engines and they are good ones. This is the administration layer around one. If your problem is writing a policy, use Gatekeeper. If your problem is that nobody can tell you which policies are actually live in staging versus production, that is what this fixes.
- Why not just point Argo CD at a folder of policy files?
- You can, and it will tell you the files are synced. It will not tell you whether a policy is enforcing, what it has denied this week, or what it would deny if you promoted it. Doing only policy is what makes those questions answerable.
- Do I have to write Rego?
- For anything custom, yes — we are not inventing a dialect on top of OPA. The common constraints ship as a library you reference and parameterize instead of writing. Anything you do author is ordinary Rego and stays portable to any OPA deployment, including one that is not ours.
- How does it fit with the rest of the platform?
- RBAC decides who may act. Driftless decides the conditions under which the action is allowed, and enforces them when the change is submitted. Registry publish rules, pipeline permissions, and workload constraints all become the same kind of object in the same repository.
Know what your cluster enforces
Not what someone declared eighteen months ago and nobody has checked since.