Multi-Cloud Governance and Policy as Code

By Khimananda Oli | Last reviewed: August 2026

Managing infrastructure across AWS, Azure, and GCP without automated guardrails is a compliance liability waiting to materialize. Multi-Cloud Governance and Policy as Code solves this by embedding regulatory requirements directly into your deployment pipelines, ensuring that security standards are enforced programmatically rather than through manual review. This approach shifts compliance left, allowing teams to scale globally while maintaining the rigorous audit trails required for SOC 2 and ISO 27001 certification.

What is Multi-Cloud Governance and Policy as Code?

In my experience helping Nepali fintechs and global SaaS companies achieve SOC 2 compliance, the biggest failure point isn't a lack of security tools—it's configuration drift. A developer opens port 22 on an EC2 instance for debugging, forgets to close it, and three months later an auditor flags it as a critical finding. Policy as Code with OPA and Conftest eliminates this gap by treating governance policies as software artifacts. Instead of writing prose in a wiki that nobody reads, you write executable logic that blocks violations before they reach production.

The core value proposition is determinism. When you define a rule stating "all storage buckets must have encryption enabled," that rule applies identically whether you are deploying to us-east-1 or ap-southeast-1. For organizations operating in Nepal with data residency concerns, this means you can codify geographic restrictions that physically prevent data from leaving specific regions, turning legal requirements into unbreakable software constraints.

How do you implement Policy as Code with Open Policy Agent?

Open Policy Agent (OPA) has emerged as the CNCF graduated standard for cloud-native policy. Unlike vendor-specific tools, OPA uses Rego, a declarative query language that works across Kubernetes, Terraform, Envoy, and custom APIs. The learning curve is real, but the payoff is a unified governance layer that doesn't lock you into a single cloud provider's ecosystem.

Writing Your First Compliance Rule

A common mistake I see in Infrastructure as Code with Terraform projects is testing policies only after deployment. With OPA, you test locally first. Here is a practical Rego policy that denies AWS S3 buckets lacking server-side encryption:

package terraform.aws.s3

import rego.v1

# Deny S3 buckets without server-side encryption
deny contains msg if {
    some i
    resource := input.resource_changes[i]
    resource.type == "aws_s3_bucket"
    not has_server_side_encryption(resource)
    msg := sprintf("S3 bucket '%s' must have server-side encryption enabled", [resource.address])
}

has_server_side_encryption(resource) if {
    resource.change.after.server_side_encryption_configuration[_].rule[_].apply_server_side_encryption_by_default.sse_algorithm
}

# Unit test data
test_deny_unencrypted_bucket if {
    deny with input as {
        "resource_changes": [{
            "type": "aws_s3_bucket",
            "address": "aws_s3_bucket.logs",
            "change": {"after": {}}
        }]
    }
}

This policy evaluates the Terraform plan JSON output. The key insight is that you are validating the intent (the plan) before the action (the apply). Run this locally with opa test -v to verify logic before it ever touches your CI pipeline. In production, integrate this via conftest test tfplan.json in your GitHub Actions or GitLab CI workflow.

Integrating with CI/CD Pipelines

Enforcement must be mandatory, not advisory. Configure your pipeline to fail the build if any deny rules trigger. For teams using GitHub Actions or GitLab CI, add a dedicated policy gate between the terraform plan and terraform apply stages. Store your Rego files in a separate repository or a dedicated directory within your IaC repo, version them alongside your infrastructure code, and treat policy changes with the same code review rigor as application code.

Which tool should you choose: OPA vs Terraform Sentinel vs Cloud Native?

Selecting the right engine depends on your existing stack, team skills, and multi-cloud maturity. There is no universal best choice, only the right trade-off for your context. I've deployed all three in production environments ranging from Kathmandu-based startups to multinational enterprises.

If you operate across multiple clouds and use Kubernetes, OPA is the strategic choice in 2026. Its universality prevents vendor lock-in and aligns with the CNCF landscape. If you are exclusively on Terraform Cloud/Enterprise and don't need runtime K8s enforcement, Sentinel offers tighter integration with less setup friction. Cloud-native tools like AWS Config remain useful for baseline detective controls but fail as preventive multi-cloud governance solutions because their rule formats are incompatible across providers.

How do you enforce governance at runtime in Kubernetes?

Pre-deployment checks catch planned violations, but runtime enforcement catches drift, manual changes, and rogue operators. In Kubernetes, this means deploying OPA Gatekeeper or Kyverno as an admission controller. Every API request to create or update a resource passes through your policy engine before being persisted to etcd.

Deploy Gatekeeper with its audit controller enabled. The webhook handles preventive enforcement (blocking bad deploys), while the audit controller runs periodically to detect resources that existed before Gatekeeper was installed or were created through API bypasses. Define ConstraintTemplates for reusable policy logic and Constraints for environment-specific parameters. For example, a template requiring container security contexts can be instantiated differently for staging (warn) versus production (deny).

A practical tip from hard-won experience: always start in dryrun mode. Deploy your constraints with enforcementAction: dryrun first, monitor the violation reports for two weeks, then switch to deny. This prevents accidentally blocking legitimate workloads due to overly broad Rego logic. Pair this with Kubernetes RBAC hardening to ensure developers cannot simply delete the webhook configuration when frustrated.

How do you automate compliance evidence for SOC 2 and ISO 27001?

Auditors don't trust your word; they trust evidence. Policy as Code transforms compliance from a quarterly panic into continuous verification. When your policies live in Git, every commit hash becomes an auditable artifact proving what rules were active at any point in time. This is foundational for automating SOC 2 compliance evidence in modern CI pipelines.

1. Version-control all policies: Use semantic versioning for policy releases. Tag commits that correspond to audit periods so auditors can checkout the exact rule set active during the review window.
2. Log every decision: Configure OPA/Gatekeeper to emit structured logs for every allow/deny decision. Ship these to your centralized logging stack. These logs serve as immutable proof of enforcement.
3. Generate compliance reports automatically: Write scripts that query Gatekeeper's constraint status endpoints and generate human-readable compliance dashboards. Schedule these weekly and store them in an immutable S3 bucket with object lock enabled.
4. Map policies to control frameworks: Annotate your Rego files with metadata linking each rule to specific SOC 2 CC criteria or ISO 27001 Annex A controls. This creates a traceability matrix that auditors can validate independently.
5. Test your tests: Maintain unit tests for every policy rule. Test coverage reports demonstrate to auditors that your governance logic itself is validated and reliable.

For Nepal-based companies serving international clients, this level of automation bridges the trust gap. You're not asking clients to take your word on data protection—you're providing cryptographically verifiable proof that your infrastructure enforces their requirements continuously.

Getting Started with Multi-Cloud Governance and Policy as Code

Start small and expand. Pick one high-risk control—public S3 buckets, privileged containers, or missing encryption—and codify it first. Get that rule passing tests, integrated into CI, and running in dry-run mode before adding complexity. Resist the urge to write 50 policies on day one; exhausted teams disable enforcement when false positives block legitimate work. Build trust incrementally.

Your governance framework should evolve with your infrastructure. Revisit policies quarterly, retire rules that no longer reflect actual risk, and add new ones as your threat model changes. Treat policy code with the same engineering discipline as application code: peer review, testing, versioning, and observability. If you're building a multi-cloud platform and need help designing a governance strategy that actually sticks, reach out to discuss your architecture.