GitOps for Regulated and Critical Infrastructure Environments: Gitless Deployment with OCI and Flux

The Flux D2 Reference Architecture offers a modern, security-first answer: instead of Git, an OCI registry (such as JFrog Artifactory or Harbor) becomes the sole source of truth. Deployments happen through signed, immutable OCI artifacts that are verified and installed directly on the cluster - with no Git access from inside the cluster. This “Gitless GitOps” architecture fully decouples source code management from deployment, reduces risk, and meets the strictest compliance requirements.

Architecture Overview

At its core, the D2 architecture consists of a central container registry and three separate Git repositories for code and configuration:

• OCI Registry (single source of truth): Every Kubernetes configuration lives here as a signed, versioned container image. The registry ensures that only verified content is deployed and enables fine-grained access control through RBAC.
• fleet repository: Describes the entire fleet and tenant structure using the Flux Operator. It contains, for example, the Flux installation defined through the FluxInstance CRD and environments defined via the ResourceSet CRD.
• infra repository: Configures platform components such as monitoring, logging, ingress, policies, and cert-manager - again shipped as OCI artifacts.
• apps repository: Holds application-specific Kubernetes configurations, CI/CD flows, and per-environment rollouts.

The key shift: repositories now serve only as source-code history - no longer as deployment targets. Deployment happens exclusively through container images that land in the registry. Git is no longer the link between CI and CD.

The Gitless Deployment Flow

The D2 architecture splits the GitOps workflow into three clearly separated phases:

1. CI: Build & Sign

A merge into the main branch (for example, main) triggers a CI pipeline (for example, GitHub Actions) that runs the following steps:

• Kubernetes manifests are rendered with Helm or Kustomize.
• The manifests are packaged into an OCI-compliant container image using the Flux CLI.
• The image is signed with cosign - keyless and via OIDC through GitHub (no secret key required).
• An SBOM (Software Bill of Materials) and metadata such as build ID or workflow name are embedded alongside.
• The finished image is pushed to the registry, for example as my-app:latest.

Important: on GitHub or GitLab, this CI pipeline needs no secrets - neither for signing nor for pushing - because it can rely on the OIDC token available in the pipeline job (GitHub, GitLab).

2. CD: Deployment via Flux

Flux is installed in every target environment and subscribes to a specific OCI artifact through an OCIRepository. As soon as a new image becomes available, Flux performs the following steps:

• Pull the image from the registry.
• Verify the signature (only CI-signed images are accepted).
• Extract the manifests from the image and apply them.

The punchline: all control lives in the registry. The cluster no longer knows Git - it trusts signed, verified artifacts alone.

3. Promotion Pipeline

A central concept in D2 is tag-based promotion:

• CI first pushes to my-app:latest, which is deployed to the staging environment.
• After tests pass, a “promotion push” follows: for example, as my-app:stable or with a SemVer tag such as v1.2.3.
• The production environment follows only this “stable” tag.

This model replaces the classic “Git branch per environment” pattern with safe, traceable tagging - promotion becomes an explicit, auditable act.

Why This Architecture Fits KRITIS (Germany’s regulatory framework for critical infrastructure) and Regulated Industries

Immutable Infrastructure via OCI Artifacts

Every configuration is stored as an immutable, versioned image. You can always retrace which manifests were deployed. No blind “kubectl apply”, no drift.

Signed Deployments by Default

Flux only deploys images with valid signatures. Signing happens automatically inside CI - keyless, with no private keys. This protects against supply chain attacks and unauthorized changes.

Full Traceability and Audit Logs

Every step - from commit through build to deployment - is traceable:

• Git commit → GitHub Actions run → OCI image with SBOM and provenance
• Registry logs show who pushed which image and when.
• Flux logs record when each image was deployed and where.

Staged Rollouts with Promotion Control

Rollouts follow a defined process: only approved images (for example, those carrying the stable tag) reach production. Tests and approvals are prerequisites for promotion - nothing ships by accident.

Granular Access Control via Registry RBAC

The registry becomes the control plane: only CI workflows may push to production tags. Developers may only have access to staging tags. Separation of duties is enforced at the infrastructure layer.

No Secrets in CI/CD

Thanks to OIDC and keyless signing, both CI and cluster operate without classical secrets. No risk from leaked keys or tokens.

Git Is No Longer a Single Point of Failure

If Git goes down or gets compromised, the deployment process keeps working - because Flux trusts the registry, not the Git repo. The attack surface shrinks drastically.

Conclusion

The D2 architecture model from Flux and ControlPlane is a landmark answer for GitOps in security-critical and heavily regulated environments. By decoupling Git from deployment, using OCI artifacts, and enforcing end-to-end signature verification, it delivers:

• maximum traceability,
• a clear, secure promotion strategy,
• and uncompromising control over every change.

Organizations in critical infrastructure sectors, regulated industries, or any environment with high security demands can build modern CI/CD processes on this foundation - with no compromise on security or compliance.

Reference: Based on ControlPlane’s D2 Reference Architecture, the FluxCD documentation, and best practices around OCI, cosign, and GitHub OIDC.