GitOps

GitOps makes Git the single source of truth for infrastructure and applications: the target state resides versioned in the repository, and agents continuously reconcile it with reality. This article explains the pull principle together with its audit advantages and the difference from classic CI/CD deployment.

What is currently running in production? In many environments, this question is surprisingly hard to answer: deployments ran via scripts, someone adjusted things manually, and the documentation lags behind. GitOps answers the question with a glance at the repository. The desired state of infrastructure and applications is declared in Git, and automatic agents ensure that reality matches this state. The term was coined in 2017 in the Kubernetes environment; as an operating pattern for containerized platforms, it has established itself widely since then.

What is GitOps?

GitOps is an operating model for cloud-native environments that rests on four principles. First, the target state is described declaratively: configuration files define what should run, no script describes how to get there. Second, this target state resides versioned and immutable in Git, including the complete history. Third, software agents pull changes on their own instead of an external system pushing them into the environment. Fourth, these agents continuously reconcile the actual and target state and correct deviations automatically. The model originated in the Kubernetes environment. The principles can, however, be transferred to any declaratively controllable system, for example to network and security policies.

How it works

Declarative definition: Manifests describe applications along with their configuration as a target state. Templating and overlays keep the definitions maintainable across several environments.
Change via pull request: Every adjustment goes through the same path as application code: branch, review, approval, merge. In the target picture, there is no legitimate way past this process.
Pull instead of push: An agent inside the target environment observes the repository and applies changes itself. As a result, external systems need no privileged access into the environment.
Continuous reconciliation: The agent continuously compares the real state with the declared one. Manual interventions directly on the system are detected and automatically reverted.
Rollback via history: A faulty state is corrected by reverting the corresponding commit. The recovery is thus just as traceable as the original change.

Why it matters

A complete audit trail: every change to the environment exists as a commit with author, timestamp, and review. Auditors receive the change history without separately maintained documentation.
Fewer privileged accesses: since agents pull changes from within the environment, powerful deployment accesses from outside are eliminated. This noticeably reduces the attack surface.
Reproducibility: an environment can be rebuilt from the repository. This speeds up disaster recovery as well as setting up additional clusters or locations.
Protection against configuration drift: undocumented manual actions directly on the system do not survive the next reconciliation. Actual and target state remain permanently in sync.
Clear responsibilities: the pull request process enforces reviews and documents decisions exactly where the change takes place.
One process for everything: application and infrastructure changes follow the same path. This reduces specialized knowledge and makes cover arrangements in the team easier.

Typical scenarios

GitOps plays to its strengths wherever many similar environments are operated. Platform teams manage dozens of Kubernetes clusters from a single repository and roll out changes in a controlled way across stages. In regulated industries, the model provides evidence of who approved which change and when, without a separately maintained change register. In disaster recovery, restoration is considerably shortened because the complete target state is available versioned. And increasingly, network and segmentation policies move into this process as well: firewall rules and policies are reviewed like code and then rolled out automatically. The pull model is also attractive for edge locations with narrow connectivity, because each location supplies itself as soon as it reaches the repository.

GitOps and classic CI/CD deployment: the distinction

In the classic model, the CI/CD pipeline also handles the deployment: after build and tests, it pushes the result into the target environment via a script and stored credentials. This works but has two structural weaknesses. The pipeline needs permanent, far-reaching access rights to production. And after the deployment its responsibility ends: if the environment drifts afterwards, no one notices. GitOps separates the responsibilities. The CI pipeline continues to build and test artifacts, but the rollout is handled by the agent in the environment, which additionally watches over compliance with the target state on a permanent basis. GitOps therefore by no means replaces CI, it replaces the push step at the end of the chain. For existing environments, a gradual switch is advisable: first a non-critical application, then the rest once processes and responsibilities are well practiced.

Working with KAEMI

The principles behind GitOps also shape KAEMI's network operations. In Microsegmentation , policies arise declaratively: they describe which workloads are allowed to communicate with each other and are enforced automatically instead of being maintained by hand on individual systems. Changes thereby remain traceable, and deviations stand out. You benefit from this model even without Kubernetes, because traceable policy upkeep is a gain in every network. For the introduction of such ways of working, KAEMI provides support with Professional Services : from the assessment of your existing deployment processes to the permanent operation of the automated rule sets as a managed service. If you want to move your infrastructure and security policies into versioned, auditable processes, you can reach us via Contact .

Frequently asked questions about GitOps

Does GitOps work exclusively with Kubernetes?

No, but that is where it originated and matured the most. Kubernetes is particularly suitable because it works declaratively and agents can handle the reconciliation directly in the cluster. The principles, versioned target state and automatic reconciliation, can be transferred to other declaratively controllable systems, for example cloud resources or network policies. What matters is that the target state can be described as code.

What happens with manual changes directly to the environment?

The agent detects the deviation at the next reconciliation and resets it to the state declared in Git. This protects against undocumented interventions but requires discipline: emergency interventions too must subsequently flow back into the repository. Defined break-glass processes have proven effective, in which reconciliation is briefly paused and the intervention is afterwards recorded as a commit.

Does GitOps replace my existing CI pipeline?

No. The CI pipeline keeps its tasks: build code, run tests, create artifacts, and publish them to a registry. GitOps takes over the step after that, the rollout into the target environment. Instead of the pipeline pushing into production, it updates a version reference in the configuration repository, and the agent in the environment applies the change. Both building blocks complement each other.

What security advantages does the pull principle offer?

In the push model, an external system holds permanent credentials with far-reaching rights to production, a worthwhile target. In the pull principle, the agent pulls changes from within the environment. Toward the outside, read access to the repository and registry is sufficient. If the CI environment is compromised, the attacker lacks direct deployment access, and every effective change remains visible as a commit.

Is GitOps also suitable for network and security policies?

Yes, the transfer is obvious. Segmentation rules and firewall policies are declarative descriptions of permitted communication and benefit from the same mechanisms: review before every change, a complete history for audits, and automatic reconciliation against the enforced state. Manually maintained rule sets, by contrast, tend to drift quickly in practice. KAEMI implements this idea in the operation of segmentation policies.