If you run a Kubernetes platform, you have probably felt how quickly networking decisions can become a platform bottleneck. An application team needs a new egress rule. Another team is onboarding and wants an ingress to a new service. A security review demands proof that traffic between two namespaces is denied by default. The problem: each request lands in your queue as a ticket, gets translated into YAML, and there is no approval chain or audit trail. A month later, nobody can answer who approved it. GitOps changes that operating model. Instead of platform teams manually translating network requests into YAML and applying them by hand, operations happen through pull requests. The desired state lives in Git, changes go through familiar review processes and merge gates, and Argo CD keeps the cluster synced to what was approved. Networking that is in Git inherits the same approval chain and audit trail as application code. Cilium aligned Gitops methodology to connectivity and security. Gateway API routes, CiliumNetworkPolicy, egress controls, load balancing resources, and observability configuration can all be managed as Kubernetes resources. The platform team owns the shared infrastructure and guardrails. Application teams own the routes and policies for their workloads. Kyverno, a CNCF Kubernetes-native policy engine, enforces the security standards the platform team requires; like ensuring traffic between namespaces defaults to denied instead of relying on convention. This post lays out what becomes possible when Cilium is the networking foundation for a GitOps platform: application teams work through Git, platform teams set the controls, and Cilium enforces the result at runtime. If you want to practise the pattern end to end, the new hands-on lab, GitOps Platform Engineering with Cilium, walks through it in a live environment. It is designed for platform engineers and application teams who want to see how policy, routing, delivery, and troubleshooting fit together in a GitOps workflow. Why Cilium Belongs at the Base of Your Platform Platform teams choose Cilium because it gives them a broad set of networking capabilities to build into the platform. For example, Gateway API provides ingress and routing features that application teams rely on for access to their application. CiliumNetworkPolicy gives application teams L3, L4, and L7 policy controls for their own workloads. Egress, load balancing, and Hubble visibility are more examples of Cilium’s capabilities that Isovalent hears from customers are key to a successful application deployment. The pattern is consistent across those capabilities: the platform team owns the control of the platform and its capabilities, and application teams consume it through Kubernetes resources that can be reviewed, delivered, and audited through GitOps. The controls in that table can live in Git, be reviewed in a pull request, be applied by Argo CD, and be enforced at runtime by Cilium without making every network change wait on a platform ticket. Git includes an audit trail: every change has an author, reviewer, timestamp, and rationale. The observability layer gives both teams the evidence they need after the change lands: which flows were allowed, which were dropped, and which policy version was active at the time. The Division of Labour Every shared platform needs a clear ownership model. In a Cilium-based GitOps platform, that model separates the capabilities the platform team provides from the resources application teams manage: Two things make this split work in practice. First, app teams never touch Argo CD, Kyverno, or the platform repo. They open pull requests against their own repository. Argo CD watches those repos. Kyverno enforces what they are allowed to ship. Second, the boundary objects are namespace-scoped. The platform Gateway opts in by label which namespaces are allowed to attach HTTPRoute resources to it: The app team writes a route, references the gateway by name, and lets Cilium handle the rest: The platform team controls who can attach. The app team controls what they expose. Neither team can break the other's contract by accident. Day One Without Guardrails Before the pattern, look at what fails when teams share a cluster without it. The lab opens with this exact scenario, and it is worth showing the failure mode because it is the one most platforms have lived with. Imagine two teams writing CiliumNetworkPolicy resources for the same workload. The first locks down ingress to port 8080 from a specific frontend. The second adds a monitoring rule, but forgets to specify toPorts: Cilium policies are additive. The second rule does not weaken the first; it adds another permitted ingress source on every port the workload listens on. The salary endpoint that the first team carefully restricted is now reachable by anything labelled app: monitoring. There is nothing wrong with additive semantics. They are correct, and they are what makes multi-team policy composition possible. What is wrong is letting policies into the cluster without anyone catching that the second one is too broad. That is the gap a platform should close. The Four StepControl Model In our Instruqt lab, the GitOps workflow uses four checks between a developer's keyboard and a packet on the wire. This is not the only way to design a GitOps platform, and it is not meant to be a definitive reference architecture. Every organization will have its own approval paths, risk model, compliance requirements, and tooling. The value of the lab is that it gives you a concrete pattern to work from: each layer catches a different class of mistake, and each layer can be adapted to fit your platform. Step 1: Policy intelligence in CI isopolicy is an Isovalent CLI tool for reasoning about Cilium network policies before the change is applied to runtime state. Developers do not need to become policy experts for this to be useful. The platform can bring policy intelligence into the pull request, where teams are already reviewing the change. At a high level, isopolicy gives platform teams three useful modes. lint performs static analysis on Cilium network policies and highlights potential issues. tune uses observed Hubble flows to suggest tighter policies for existing broad rules. simulate lets teams experiment with adding, updating, or deleting policies and see which workloads or identities would be affected before that change is active. That last mode is especially valuable in GitOps. Policy linting goes far beyond checking valid YAML syntax. Behavior linting matters equally, if not more: does this policy do what you intended, or does it accidentally open access you didn't anticipate? Simulation answers that question before merge. A pull request can include not just the YAML diff, but an impact summary: which application paths gain access, which lose it, and whether the proposed policy still matches the workloads that are actually running. By using flow data from Hubble Relay or Timescape, simulation turns recent traffic into practical reviewer context. The reviewer sees not just whether the policy is syntactically correct, but what it will actually do in production. The platform owner decides which findings are advisory and which findings block merge. In the lab, the CI workflow posts analysis back to the PR and blocks selected policy problems, such as a rule that references a port the target workload does not expose. Step 2: Kyverno admission control Kyverno enforces the rules the platform team is not willing to negotiate. The lab ships two: If a CiliumNetworkPolicy arrives at the API server without a team label, the apply fails before the resource ever reaches etcd. There is no "soft" failure, no eventual consistency hole. The platform team gets the audit trail it needs (every policy is attributable), and app teams get a deterministic error. A second Kyverno policy blocks CiliumNetworkPolicy resources from landing in default. Together, the two policies enforce conventions that, on a manually managed cluster, exist only as wiki pages. Step 3: Argo CD selfHeal The third layer deals with a different problem: drift after a valid change has already landed. GitOps only works if the cluster keeps returning to the state described in Git. Without that reconciliation loop, a well-governed pull request process can still be bypassed by a manual edit during an incident, a late-night fix, or a debugging session that never gets cleaned up. selfHeal: true is the setting that closes that loop. If somebody runs kubectl edit ciliumnetworkpolicy webapp-ingress to "just fix it for a minute," Argo CD reconciles back to Git within seconds. The cluster stops being a place where state is created. It becomes a place where state is rendered. For platform teams, this changes the question of "who changed what" from a forensic exercise into a simple audit trail: the change is in Git, with the author, reviewer, timestamp, and reason captured alongside it. Step 4: Cilium in the kernel The final layer is runtime enforcement. Once the approved policy reaches the cluster, Cilium applies it to the workloads it selects and enforces the allowed traffic paths. The previous layers decide whether the change should be accepted. Cilium enforces the approved policy against the workloads it selects, so the reviewed intent becomes the runtime behavior. You can verify enforcement with Hubble: Identity-based, not IP-based. That is why the policy is still correct after the next rolling update. Hubble CLI is useful for quick validation, but most teams need a shared place to investigate policy behavior over time. That is where Timescape becomes part of the operating model. Troubleshooting with Timescape The four layers above decide whether a policy change is allowed and whether the cluster stays aligned to Git. They do not remove the need for investigation. When traffic is dropped, the application team needs to understand what changed for its workload, and the platform team needs to know whether the shared guardrails behaved as intended. Timescape is for troubleshooting. It stores Hubble flow history and policy change events, so teams can quickly connect a dropped flow to the policy change that caused it. Instead of trawling through commits, guessing which merge changed the behavior, or missing a manual override that never went through Git, responders can start from the traffic symptom and work back to the relevant policy event. In the lab scenario, a direct-to-main emergency change updates a cache egress policy from app: cache to app: redis. The selector matches no workloads, webapp-to-cache traffic starts dropping, and Timescape shows both sides of the story: the dropped flows and the policy change that caused them. This makes Timescape part of the shared operating model between teams, rather than another admission gate. The same GitOps model that prevents most mistakes also provides teams a clean path to recover: confirm the failed traffic, identify the policy change, fix the policy in Git, let CI run, merge, and let Argo CD reconcile the corrected state. Application Teams Get to Move Fast The point of all this scaffolding is developer speed with platform control. Once the layers are in place, an application team can change network policy on their own without paging the platform team, because the platform has already decided in advance which changes are safe to merge. Walk through the loop in the lab as an application engineer: Open a PR adding a new ingress rule. CI runs isopolicy analysis and posts the simulation as a comment. You see exactly which identities your policy will affect. The reviewer approves. You merge. Argo CD picks up the change and tries to apply it. If you forgot the team label, Kyverno rejects the manifest from being applied to the cluster. Argo CD shows SyncError with the precise Kyverno message. You fix it in another PR. Once green, the policy is in the cluster within seconds, enforced by Cilium. The feedback loop is fast, the rules are explicit, and the platform team is not in the middle of it. That is the trade you are making with these layers: more YAML upfront in exchange for a delivery path the platform team does not have to operate by hand. What This Makes Possible for the Platform Owner To make the argument concretely: a Cilium powered GitOps platform changes three things about how a platform team operates. It changes the unit of work from "ticket" to "review." Network policy stops being something a platform engineer types. It is something they review. It changes the audit trail from "I think Sarah did this last March" to a commit history. Compliance and security reviews stop being archaeological digs. It changes the failure mode from "production incident" to "failed CI check." Bad policies do not make it to a cluster, because the layers above the cluster reject them first. None of this requires writing custom controllers, building a self-service portal, or hand-rolling a policy engine. It requires picking a CNI that exposes networking as Kubernetes resources, putting them in Git, and standing up delivery, guardrail, enforcement, and observability layers around them. Get Started Using GitOps with Cilium in Our Lab The idea behind this post is simple: bringing Cilium resources under GitOps control makes networking and network policies part of the platform contract. Application teams can enable access for their own workloads through Git, while platform teams set the guardrails that stop one team's change from affecting everyone else. In GitOps Platform Engineering with Cilium, you start with the problems many platform teams recognize: shared clusters with unlabeled policies, additive Cilium rules that open more access than intended, manual drift, and broad rules that land without review. From there, you build the controls around the platform. You will work with separate platform and application repositories, use Argo CD to reconcile both, add Kyverno guardrails for Cilium policy standards, manage Gateway API and egress gateway resources through Git, add isopolicy analysis to the pull request flow, and use Timescape to investigate a policy incident after the fact. The final exam asks you to ship a new application path through the same model: diagnose a rejected exposure attempt, fix a blocked policy PR, complete an HTTPRoute, merge through CI, and verify the result. The goal is to experience the operating model, not memorize one YAML layout: app teams work through Git, platform teams define the guardrails, Cilium enforces the approved policy, and Timescape gives both teams a faster way to troubleshoot what happened. Looking to dive even deeper into Gitops and Argo CD? Why not check out “Argo CD: Up and Running” written by Isovalent’s Christian Hernandez. If this is the direction you want to take your platform, or you need help turning Cilium and GitOps into a working model for your teams, get in touch with Isovalent.