Learn Cilium - Cilium in GitOps & Policy as Code

#Introduction

So far we have applied all Cilium configuration manually from the terminal. Episode 18 fundamentally changes that approach: everything becomes code — Helm configuration, CiliumConfig, and CNP/CCNP policies are stored in Git, applied automatically, and reviewable like an ordinary pull request. This is the practice of GitOps and Policy as Code.

Why does this matter for Cilium in particular? Because policies are sensitive: a single mistake can block all traffic. With Git, every change is recorded, reviewable, rollback-able, and can be rolled out gradually. This is not just convenience — it is quality control over something that directly affects the entire cluster.

#Managing Configuration as Code

The first principle of GitOps: the desired state is declared in a repository, and a controller always syncs the cluster toward that state. For Cilium, three layers are declared:

• Helm values: installation configuration such as IPAM, encryption, or the datapath mode.
• CiliumConfig: configuration that can be changed without reinstalling the chart.
• Policy: CNPs and CCNPs as ordinary manifests.

All of this is stored as YAML files in the same repository as the rest of the infrastructure configuration. No more manual cilium install commands in production; everything is pulled from Git by the controller.

#CiliumConfig for Helm

CiliumConfig is a resource that lets certain configuration be changed without reinstalling the chart. Here is an example definition:

apiVersion: cilium.io/v2
kind: CiliumConfig
metadata:
  name: cilium
  namespace: kube-system
spec:
  debug: false
  ipam:
    mode: cluster-pool
  kubeProxyReplacement: strict

spec.kubeProxyReplacement: strict is an example of a setting declared as code. Because this file lives in Git, every datapath or IPAM mode change is recorded complete with who changed it and when.

#CNP/CCNP Policies in Git

Policies also become ordinary manifests. Store all CNPs and CCNPs in one tidy directory so they are easy to review and audit:

tree policy/

tree policy/ shows the policy directory structure, for example the files policy/frontend/allow-ingress.yaml and policy/global/blokir-debug-port.yaml. Each file is reviewed via pull request before it is merged, and the history of policy changes can be traced at any time.

With this structure, the classic question "who changed the ingress policy yesterday?" is answered with just git log — no guessing from memory.

#Argo CD and Flux

Two commonly used GitOps tools: Argo CD and Flux. Both can manage Helm releases and custom manifests.

These two tools differ in style: Argo CD is application-based with a rich UI and "sync"-based operations, while Flux is closer to raw Git with strict reconciliation and one-way support from Git to the cluster. Choose based on your team's preference, not on features that both already have — most core features are equivalent.

Here is an example Argo CD Application for managing Cilium:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cilium
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://git.example.com/platform/cluster.git
    path: cilium
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: kube-system
  syncPolicy:
    automated:
      prune: true

spec.source.path: cilium points to the Cilium manifests directory in the repository. With automated.syncPolicy, every change in Git is synced to the cluster immediately. Flux uses HelmRelease and Kustomization in the same spirit — pick one and use it consistently.

#Best Practices: Versioning, Review, Canary

Making policies into code is only half the job. The other half is how you manage them:

• Versioning: store policies in the same repository as the application code or in a separate infra repository; use clear tags and history.
• Review flow: require at least one reviewer for policy changes, especially those touching global policies.
• Canary: apply a policy to one namespace or one workload first, observe Hubble and metrics, then expand scope.

Here is a safe canary pattern: apply a new policy with an endpointSelector that only covers the staging namespace, run cilium connectivity test there, and only after it passes, expand the selector to production.

#Gradual Rollout in Practice

Before letting GitOps apply policies automatically, get into the habit of validating manifests in the terminal first. Two commands that prevent mistakes from reaching the cluster:

kubectl apply --dry-run=server -f policy/frontend/allow-ingress.yaml
kubectl diff -f policy/frontend/allow-ingress.yaml

kubectl apply --dry-run=server -f policy/frontend/allow-ingress.yaml validates the manifest against the API server without applying it — catching syntax and schema errors before they have an impact. kubectl diff -f policy/frontend/allow-ingress.yaml shows the difference between the current state and the state to be applied, so reviewers can see exactly what changes.

For Argo CD, follow a safe sync flow:

argocd app diff cilium
argocd app sync cilium --prune --dry-run
argocd app sync cilium

argocd app diff cilium shows the difference between Git and the cluster. argocd app sync cilium --prune --dry-run simulates the sync without changing anything. Only after both are clean, run argocd app sync cilium to actually apply.

A principle to hold on to: previewing is always cheaper than rolling back. Full automation is attractive, but for something as sensitive as policies, one extra preview step in the pipeline or in the manual workflow is worth far more than a few seconds of speed.

#Closing

Key takeaways:

• GitOps turns Cilium configuration into recorded, reviewable code.
• Three code layers: helm values, CiliumConfig, and CNP/CCNP policies.
• CiliumConfig changes configuration without reinstalling the chart.
• Argo CD and Flux are the main tools for syncing Git to the cluster.
• Versioning, review flow, and canary keep the quality of policy changes high.
• Use auto-sync wisely: automatic for configuration, cautious for policies.

In the next episode 19, we will cover performance and troubleshooting — using cilium-dbg for endpoints, identity, and policies, collecting diagnostics with cilium-bugtool, monitoring traffic with cilium monitor, and solving common problems such as policies rejecting traffic, missing identity, and IPAM running out of pool. This is the toolkit you will carry into production.