GitOps as a Revision Authority

In regulated financial and software environments, two opposing worlds collide: development teams demand maximum release speed through automated CI/CD pipelines, while bank auditors and regulators, following DORA (Digital Operational Resilience Act) and MaRisk, require comprehensive, tamper-proof evidence for every single system change. In practice, this tension often leads to bureaucratic ticket systems and manual approval processes that slow down modern DevOps cycles and still cannot prevent configuration drift on production systems.

The solution to this dilemma lies in the paradigm shift from procedural ticket workflows to declarative platform operations. By establishing GitOps as a revision authority, version control becomes the sole source of truth for infrastructure and applications. ayedo transforms ICT change management from an error-prone documentation project into a technically enforced, auditable feature of ongoing operations.

The Problem: When Manual Approvals Jeopardize Governance

Traditional change management methods rely on retrospective documentation and create a dangerous delta between the documented desired state and the actual cluster reality. Three structural weaknesses characterize insufficiently automated operations:

1. The Phenomenon of Unnoticed Configuration Drift

When hotfixes or parameter adjustments are made directly via CLI (kubectl edit) or through cloud web consoles on production nodes during crises, the documentation in the ticket system becomes obsolete. The actual cluster state drifts from the documented state. During subsequent deployments or failures, this invisible state leads to unpredictable cascading effects and breaks any audit trail of consistency.

2. Operational Inertia Due to Asynchronous Approval Loops

Traditional Change Advisory Boards (CAB) and multi-level ticket approvals create artificial waiting times of days or weeks. Developers are blocked, small functional changes accumulate into risky mega-releases, and the Mean Time to Resolution (MTTR) for security-critical patches rises to a regulatorily unsustainable level.

3. The Gap in Forensic Reconstruction

During DORA audits or security incidents, auditors demand an exact answer to the question: Who authorized and implemented which configuration change at what time? If this history has to be painstakingly reconstructed from ticket logs, CI build logs, and terminal histories, incomplete audit trails are created that do not withstand regulatory standards.

The Solution: Declarative Reconciliation and Cryptographic Audit Trails

ayedo implements GitOps via ArgoCD as a systemic core component of the platform architecture, ensuring that every change to infrastructure, network policies, and application workloads is technically immutable and traceable.

1. The Single Source of Truth in Versioned Git Repositories

All infrastructure definitions, Helm charts, Cilium network policies, and Kubernetes manifests are stored declaratively in protected Git repositories. Direct write access to the cluster API via kubectl is completely restricted for humans. The desired state exists solely as code and is versioned through cryptographically signed commits.

2. Enforcing the Four-Eyes Principle via Branch Protection

Changes to production environments can only be initiated through pull/merge requests. Through automated policy-as-code validations and strict branch protection rules, the system mandatorily requires qualified approvals. Security checks (such as CVE scans via Harbor and static manifest analyses) run fully automatically before the merge – thus, compliance with banking supervisory release requirements is enforced by software.

3. Continuous State Reconciliation and Automatic Drift Correction

The ArgoCD controller operating in the cluster continuously compares the live state with the desired state defined in the Git repository. If a parameter in the cluster deviates – due to manual manipulation or faulty processes – the reconciliation loop pattern detects this state in real-time and automatically overwrites it with the authorized Git state (self-healing).

Strategic and Economic Benefits

• 100% Traceability for DORA, ISO 27001 , and MaRisk Audits: The Git history serves as an immutable, cryptographically secured audit trail. Every change, approval, and rollout time is verifiably documented without manual re-entry.
• Radical Reduction of MTTR and Error-Free Rollbacks: If a deployment fails or an update leads to unforeseen behavior, a simple git revert is sufficient. The controller deterministically restores the previous, stable cluster state within seconds.
• Significant Reduction of Operational TCO: By eliminating manual ticket documentation and tedious audit preparations, the administrative burden for platform and development teams is reduced by over 60%.
• Complete Data Sovereignty Without US SaaS Dependency: The entire GitOps stack operates on sovereign European infrastructure in certified data centers, protecting business-critical configuration metadata from unauthorized access.

Conclusion

ICT change management in highly regulated markets must not be an administrative obstacle to modern product development. Those who map security and revision requirements through manual documentation loops lose both operational speed and actual control. A declarative GitOps operating model resolves this conflict: it transforms version control into a technical control mechanism that guarantees regulatory compliance as a natural byproduct of every deployment and keeps platforms permanently auditable.

Frequently Asked Questions (FAQ)

How are emergency fixes handled under strict DORA requirements via GitOps? Even in emergency operations, the GitOps path remains binding. Instead of manual interventions at the cluster level, an accelerated “Fast-Track PR” process with defined emergency approvers is used. Since deployment is fully automated via ArgoCD and synchronized within seconds, there is no time loss compared to manual commands – however, the forensic audit trail remains intact.

How does GitOps prevent sensitive secrets from being stored unencrypted in the Git repository? In the ayedo platform model, plaintext secrets are never stored in Git. Instead, mechanisms such as HashiCorp Vault with the External Secrets Operator or Sealed Secrets are used. Only encrypted references are stored in the Git repository; the actual decryption and dynamic rotation of credentials occur in isolation at runtime within the cluster.

Does the introduction of GitOps require a complete overhaul of existing CI pipelines? No. The existing CI pipeline (e.g., GitLab CI, GitHub Actions) continues to build application artifacts, run tests, and push Container images to the private registry. At the end of the pipeline, the CI simply updates the image tag in the GitOps repository declaratively. Deployment execution is fully handed over to ArgoCD (pull rather than push principle).