The ControlPlane distribution for Flux CD comes with enterprise-hardened Flux controllers including:
- Hardened container images and SBOMs in-sync with upstream Flux releases.
- Continuous scanning and CVE patching for Flux container base images.
- SLAs for remediation of critical vulnerabilities affecting Flux functionality.
- FIPS-compliant Flux builds based on FIPS 140-2 validated BoringSSL.
- Extended compatibility of Flux controllers for the latest six minor releases of Kubernetes.
- Assured compatibility with OpenShift and Kubernetes LTS versions provided by cloud vendors.
The ControlPlane distribution is offered on a yearly subscription basis and includes enterprise-grade support services for running Flux in production.
Tip
Connect with us to explore how the enterprise distribution aligns with your unique requirements. Together, we'll develop and review a plan tailored to your challenges, goals, and budget.
ControlPlane offers two distribution channels for the Flux controllers:
- FIPS-compliant images hosted at
ghcr.io/controlplaneio-fluxcd/distroless
. - Mainline images hosted at
ghcr.io/controlplaneio-fluxcd/alpine
.
The ControlPlane container images are continuously scanned for vulnerabilities and patched accordingly.
The ControlPlane distribution offers hardened Google Distrosless-based Flux images to organizations that must comply with NIST FIPS-140-2 standards.
The Flux controller binaries are statically linked against the
Google BoringSSL libraries,
and the Go runtime restricts all TLS configuration to FIPS-approved settings
by importing the crypto/tls/fipsonly
package.
The mainline distribution channel offers Alpine Linux-based images fully compatible with the upstream Flux feature set.
The major difference between the Flux upstream images and mainline images is the continuous scanning and CVE patching for the container base images, OS packages, and Go dependencies.
ControlPlane offers a seamless transition from CNCF Flux to the enterprise distribution with no impact to Flux availability. The hardened container images provided by ControlPlane are fully compatible with the upstream Flux installation and bootstrap procedure.
Customers can bootstrap Flux with the enterprise distribution using the Flux CLI or the Flux Terraform provider.
To access the ControlPlane registry, customers need to provide their credentials using the
--registry-cred
flag.
Example of bootstrapping Flux with the FIPS-compliant distribution:
flux bootstrap github \
--owner=customer-org \
--repository=customer-repo \
--branch=main \
--path=./clusters/production \
--image-pull-secret=flux-enterprise-auth \
--registry-cred=flux:$ENTERPRISE_TOKEN \
--registry=ghcr.io/controlplaneio-fluxcd/distroless
For keeping the Flux controllers images digests and manifests up-to-date with the latest version of the Enterprise Distribution, ControlPlane provides Kustomize images patches for the Flux manifests, which can be found in the distribution repository.
Customers using GitHub can leverage the ControlPlane GitHub Actions to automate the update of the Flux manifests in their bootstrap repositories. For more information, see the Update Flux GitHub Action documentation.
For customers using other Git providers, ControlPlane provides support for configuring automated updates for the Flux enterprise distribution.
The ControlPlane distribution comes with a set of guides and documentation to help customers configure and operate the Flux controllers in production environments.
For an overview of the enterprise offering and pricing, see the ControlPlane presentation document.
The Flux CD Architecture Overview guide provides a comprehensive overview of the Flux CD architectures, including a comparison of the deployment strategies of the Flux components when implementing GitOps for multi-cluster continuous delivery.
The aim of this guide is to provide a comprehensive description of the Flux d1 reference architecture, offered by the d1 repositories housed within the controlplaneio-fluxcd organization. These repositories and the flux d1 reference architecture guide expand upon the established Flux documentation, which includes a quickstart guide for orchestrating a single cluster. Our focus is to showcase how Flux can address the requirements of organizations managing multiple teams deploying applications across numerous multi-tenant Kubernetes clusters using Flux. Through this comprehensive resource, users can gain insights into leveraging Flux for streamlined multi-cluster management and efficient application deployment workflows.
The build, release and provenance portions of the ControlPlane distribution supply chain meet SLSA Build Level 3.
The ControlPlane images come with SBOMs in SPDX format for each CPU architecture.
Example of extracting the SBOM from the source-controller image:
docker buildx imagetools inspect \
<registry>/source-controller:v1.3.0 \
--format "{{ json (index .SBOM \"linux/amd64\").SPDX}}"
The ControlPlane images are signed using Sigstore Cosign and GitHub OIDC.
Example of verifying the signature of the source-controller image:
cosign verify <registry>/source-controller:v1.3.0 \
--certificate-identity-regexp=^https://github\\.com/controlplaneio-fluxcd/.*$ \
--certificate-oidc-issuer=https://token.actions.githubusercontent.com
The provenance attestations are generated at build time with Docker Buildkit and include facts about the build process such as:
- Build timestamps
- Build parameters and environment
- Version control metadata
- Source code details
- Materials (files, scripts) consumed during the build
Example of extracting the SLSA provenance JSON for the source-controller image:
docker buildx imagetools inspect \
<registry>/source-controller:v1.3.0 \
--format "{{ json (index .Provenance \"linux/amd64\").SLSA}}"
The provenance of the build artifacts is generated with the official SLSA GitHub Generator.
Example of verifying the provenance of the source-controller image:
cosign verify-attestation --type slsaprovenance \
--certificate-identity-regexp=^https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml.*$ \
--certificate-oidc-issuer=https://token.actions.githubusercontent.com \
<registry>/source-controller:v1.3.0
The Flux controllers (source code, binaries and container images) are continuously scanned for CVEs. Once a CVE is detected, the ControlPlane team assesses the exploitability of the vulnerability. If the vulnerability is proven to be exploitable, the ControlPlane team provides a patch within the agreed SLA and issues a security bulletin to customers containing the CVE details and the container images digests that include the fix.
There are cases where the vulnerability is not exploitable in the context of the Flux controllers, and in such cases, the ControlPlane team issues a CVE exception in the OpenVEX format.
For each Flux minor release, the ControlPlane team maintains a VEX document with the
list of vulnerabilities that do not affect the Flux controllers. The VEX documents
are available in the enterprise distribution repository under the vex
directory.
Example of scanning the source-controller image with Trivy using the VEX document:
$ trivy image <registry>/source-controller:v1.2.2 --vex ./vex/v2.2.json --show-suppressed
Suppressed Vulnerabilities (Total: 1)
┌─────────────────┬────────────────┬──────────┬──────────────┬─────────────────────────────┬─────────┐
│ Library │ Vulnerability │ Severity │ Status │ Statement │ Source │
├─────────────────┼────────────────┼──────────┼──────────────┼─────────────────────────────┼─────────┤
│ helm.sh/helm/v3 │ CVE-2019-25210 │ MEDIUM │ not_affected │ vulnerable_code_not_present │ OpenVEX │
└─────────────────┴────────────────┴──────────┴──────────────┴─────────────────────────────┴─────────┘