Policy library and testing
Rego and Kyverno rules written as versioned code with unit tests, so a policy change is reviewed, explained and proven before it starts rejecting anything.
Security & Compliance
Policy as Code
Your infrastructure rules enforced before deployment, by code rather than by review.
The work
What this actually does
Written standards decay. Someone leaves, a new service ships with a public bucket, and the wiki page that forbade it never gets read again. We turn the rules that matter into policies evaluated automatically, so a change that breaks them fails before it reaches an account or a cluster.
Open Policy Agent gives us one language for cloud plans, Kubernetes manifests and pipeline configuration, with Kyverno covering the cluster-side cases. Policies live in a repository, get unit tested like any other code, and are reviewed when they change. We start with a small set you can defend and grow it as the exceptions are worked through.
If any of these sound familiar
- The security standard exists in a document nobody opens
- Every environment is configured slightly differently for no good reason
- Someone tags a resource wrongly and the cost report is useless
- Reviewers approve plans they cannot reasonably check by eye
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Pre-merge plan checks
Terraform and Pulumi plans evaluated in the pull request, with the offending resource named in a comment rather than discovered at apply time.
Cluster guardrails
Kyverno policies that reject privileged containers, missing resource limits or unpinned images, with the option to warn first while teams catch up.
Cost and tagging rules
Required tags, allowed regions, instance size ceilings and budget thresholds, so cost control is enforced at the point of change rather than argued over later.
Warn before you block
New policies run in warn mode against existing infrastructure first, producing a report of what would fail, so nobody is surprised by an enforcement switch.
Exception workflow
A documented way to request an exemption with a reason and an expiry date, so the policy set stays credible instead of growing blanket ignores.
What changes
What teams typically see
100%Plans checked before apply
0Unreviewed policy changes
2 minAdded to plan review
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Policy repository with tests and CI validation
- Pre-merge checks wired into infrastructure pull requests
- Cluster admission policies in audit then enforce mode
- Warning reports showing what would currently fail
- Register of approved exemptions with expiry dates
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
Terraform
Kubernetes
GitHub
GitLab
Argo CD
AWS
Microsoft Azure
Google Cloud
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Harvest the real rules
We read your standards, your past incidents and the exceptions people already make, then list the rules that are both enforceable and worth enforcing.
- 02
Write and test policies
Each rule becomes code with examples of what passes and what fails, reviewed by the teams who will have to live with it.
- 03
Warn, then enforce
Policies run in a reporting mode against live infrastructure until the failure list is small enough to fix, then the switch is flipped deliberately.
- 04
Keep the set honest
We review exceptions monthly with their owners, retire rules that no longer earn their place, and add new ones only when the gap is real.
Questions
Asked before we start
Will policy checks block our engineers constantly?
At first they can, which is why every policy starts in warn mode and produces a report instead of an error. We work through the failures with the owning teams, and enforcement begins only when the remaining exceptions are deliberate.
Do we need Open Policy Agent if we use Kubernetes?
Not necessarily. Kyverno alone covers many cluster policies and is easier to adopt. OPA earns its place when you want the same policy language across Terraform plans, CI pipelines and clusters, which is common once a second cloud or team appears.
How do you avoid policy drift over time?
Policies are versioned code in a repository with owners, so changes show up in review like any other change. We add a monthly session to retire rules that have stopped mattering, because a stale policy set is the fastest way to get everything ignored.
Can policies cover things other than infrastructure?
Yes, within reason. The same engine can check pipeline configuration, container manifests and deployment settings. It cannot judge an architectural decision or whether a design is sensible, so keep the rules mechanical and leave judgement to review.
Security & Compliance
Often needed alongside this
Infrastructure & Cloud
Infrastructure as Code
Your entire cloud estate described in version control — reviewable, reproducible and rebuildable from scratch.
- Terraform, OpenTofu, Pulumi & CloudFormation
- Remote state, workspaces and modular reusability
- Drift detection and policy-checked pull requests
Security & Compliance
DevSecOps & Compliance
Security checks wired into the pipeline, so vulnerabilities are caught in review instead of in production.
- SAST, DAST, dependency and container scanning
- Secrets management with Vault, KMS and SOPS
- Policy as code and audit-ready evidence trails
Security & Compliance
Compliance Readiness
Continuous evidence collection instead of a quarterly fire drill — audit trails generated by your pipeline.
- SOC 2, ISO 27001, HIPAA and PCI DSS readiness
- Automated control evidence and reporting
- Change management and segregation-of-duties trails
Worth a conversation about Policy as Code?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.