cilium-kubernetes/README.md

Cilium

The cluster CNI is managed with cilium-cli and pinned to Cilium v1.20.0. The values in values.yaml were recovered from the live Helm release with:

cilium-cli upgrade --version v1.20.0 --dry-run-helm-values

They preserve the Kubernetes API endpoint, VXLAN tunnel routing, kube-proxy replacement, two operator replicas, and Hubble Relay/UI. The operator replicas are restricted to Odroid workers, use required pod anti-affinity so they run on different nodes, and have a disruption budget that keeps at least one available during voluntary disruptions.

Hubble TLS

Hubble mTLS certificates are issued and automatically renewed by cert-manager. hubble-pki.yaml creates a namespace-scoped internal CA; no private keys or other Secrets are committed. Do not use the public Let's Encrypt issuers for these internal Cilium identities.

L2 load balancers

There are currently no CiliumL2AnnouncementPolicy or CiliumLoadBalancerIPPool resources in the cluster. Load-balancer IPs are announced by MetalLB, so no Cilium L2 configuration was added here.

Install or reconcile

Run this from a machine with both kubectl and cilium-cli configured for the cluster. From the current location that machine is dahoam:

rsync -av cilium/ dahoam:cilium/
ssh dahoam 'cd cilium && ./install.sh'

The script creates the cert-manager CA first, then installs or reconciles the pinned Cilium release. Existing Cilium agents are restarted with a rolling DaemonSet update so they load renewed Hubble certificates before Relay is restarted and health-checked.

Gitea Actions CI/CD

Every push and pull request renders the pinned Cilium 1.20.0 Helm chart from values.yaml, verifies the chart archive against its committed SHA-256 digest, and validates the rendered resources plus the local PKI and alert manifests. A successful push to main applies that desired state and waits for Cilium, Cilium Envoy, the operator, Hubble Relay, and Hubble UI.

CI does not use Helm's release Secrets. render.sh produces plain Kubernetes resources, and the restricted deployer can update only the exact existing resource names rendered by the current chart. It cannot read Secrets, create resources, delete resources, or change Cilium CRDs. If a future chart adds or renames an object, the server-side dry-run fails before deployment; run ./install.sh once as an administrator to bootstrap that version, then update ci-deployer.yaml deliberately.

Create the deployment identity once:

./create-ci-kubeconfig.sh

For remote cluster access:

KUBECTL_SSH_HOST=arschrock ./create-ci-kubeconfig.sh

Store only the final output line as the Gitea Actions repository secret KUBE_CONFIG_BASE64. Revoke it by deleting kube-system/cilium-deployer-token, the cilium-deployer ClusterRoleBinding, and the repository secret.

The deployer cannot create arbitrary workloads, but it can patch the existing privileged Cilium workloads and has escalate/bind only for Cilium's exact named RBAC objects. Those verbs are required by Kubernetes' RBAC anti-escalation checks when reconciling Cilium's own permissions. Treat merges to main as cluster-administrator changes and require review and successful validation.

Run ./test.sh for a local render and schema validation. It requires Helm, curl, and either kubeconform or Docker.