Spirits were high as the Flux team came together in London for KubeCon + CloudNativeCon Europe this year. With plenty to celebrate and even more to accomplish, one theme stood out as omnipresent: project security.
The project’s recent efforts have included a Workload Identity RFC and participation in the CNCF’s Security Slam, and this is par for the course — Flux has always taken special care to build resilient software that is resistant to attack.
This starts with the secure design of Flux’s components themselves:
- Flux is built and signed at SLSA Build Level 3 to prevent tampering of the upstream images.
- Flux does not shell out to external binaries. We use native Go code and libraries for all of the reconcilers. This is true for Git, Helm, Kubernetes, Kustomize, and everything else, with the only exception being GPG.
- All of Flux’s API state is stored directly within Kubernetes, and NetworkPolicy controls any network traffic to the flux-system namespace.
- Each controller works on separate concerns and has RBAC scoped down to what is minimally necessary.
Our Security Documentation shows how security is first in Flux’s design.
That secure design is extended into a secure delivery mechanism with signing and verification of all assets.
Git-less GitOps
Flux supports reconciling desired state configuration from OCI Artifacts. It can also verify cosign signatures on those artifacts. This first-class support of OCI founds a scalable and secure basis for continuous delivery in even the most challenging software deployments.
Members of the Flux community have built the D2 Reference Architecture with example repos that can run on a kind cluster.
Desired state is split up into separate fleet, infra, and apps repos, and the configuration of individual add-ons and components are built into signed OCI artifacts that can then be deployed independently to different target clusters from the fleet control artifacts:
These OCI artifacts have their GitHub Actions build runner’s workflow and branch name encoded into the artifact signature, so it is possible for clusters to only accept builds that verifiably come from a specific workflow on the `main` branch.
This is enforced via OCIRepository’s spec.verify.matchOIDCIdentity field in the ResourceSets that deploy the tenants for apps, infra, and policy. Here is one example:
controlplaneio-fluxcd/d2-fleet@09236f4/tenants/apps.yaml#L68-L83
With this configuration, Flux rejects artifacts with improper build and source provenance.
Multi-tenant workload identity
Flux has a multi-tenant API — users can reconcile with least privilege using native Kubernetes ServiceAccounts. However, configuring access to Kubernetes-external cloud resources and API’s requires per-tenant secrets management.
We are working on RFC-0010 to allow multi-tenant, namespaced usage of Workload Identity for speaking to external APIs.
Some use-cases where this strengthens security and simplifies configuration are fetching sources from OCI and using KMS keys for secrets decryption.
Moving Flux forward
We’re so thankful to the folks who took time during KubeCon + CloudNativeCon Europe to make contributions on the Flux Security Slam. This group effort improved our CI workflows, added security-related metadata to the repo, and drafted the project’s self assessment with TAG Security. Read about the Security Slam Transparency Report for more.
Flux strives to provide a secure, stable, scalable basis for cloud native continuous delivery.
The Flux Project is incredibly active right now, so come join our project meetings and get involved!