|
| 1 | +--- |
| 2 | +author: Stefan Prodan |
| 3 | +date: 2025-05-29 12:00:00+00:00 |
| 4 | +title: Announcing Flux 2.6 GA |
| 5 | +description: "We are thrilled to announce the release of Flux v2.6.0! Here you will find highlights of new features and improvements in this release." |
| 6 | +url: /blog/2025/05/flux-v2.6.0/ |
| 7 | +tags: [announcement] |
| 8 | +resources: |
| 9 | +- src: "**.{png,jpg}" |
| 10 | + title: "Image #:counter" |
| 11 | +--- |
| 12 | + |
| 13 | +We are thrilled to announce the release of [Flux v2.6.0](https://github.com/fluxcd/flux2/releases/tag/v2.6.0)! |
| 14 | +In this post, we will highlight some of the new features and improvements included in this release. |
| 15 | + |
| 16 | + |
| 17 | + |
| 18 | +## Highlights |
| 19 | + |
| 20 | +Flux v2.6 marks the General Availability (GA) of the Flux Open Container Initiative (OCI) Artifacts features. |
| 21 | +The OCI artifacts support was first introduced in 2022, and since then we've been evolving Flux towards |
| 22 | +a **Gitless GitOps** model. In this model, the Flux controllers are fully decoupled from Git, |
| 23 | +relying solely on container registries as the source of truth for the desired state of Kubernetes clusters. |
| 24 | + |
| 25 | +In the last couple of years, the OCI feature-set has matured, and we've seen major financial institutions |
| 26 | +and enterprises adopting Flux and OCI as their preferred way of managing production deployments. |
| 27 | +To see it in action, you can check the reference architecture guide made by ControlPlane |
| 28 | +on how industries can securely implement |
| 29 | +[Gitless GitOps with Flux and OCI](https://control-plane.io/posts/d2-reference-architecture-guide/). |
| 30 | + |
| 31 | +In this release, we have also introduced several new features to the Flux controllers, |
| 32 | +including digest pinning in image automation, object-level workload identity for container registries |
| 33 | +and KMS services authentication, and various improvements to notifications. |
| 34 | + |
| 35 | +In ecosystem news, there is a new release of [Flux Operator](https://github.com/controlplaneio-fluxcd/flux-operator) |
| 36 | +that comes with a Model Context Protocol (MCP) implementation for allowing AI assistants to interact with Flux. |
| 37 | +For more details on the Flux MCP Server, see the [AI-Assisted GitOps blog post](https://fluxcd.io/blog/2025/05/flux-mcp-server/). |
| 38 | + |
| 39 | +## General availability of Flux OCI Artifacts |
| 40 | + |
| 41 | +This release marks the General Availability (GA) of Flux [OCIRepository](/flux/components/source/ocirepositories/) |
| 42 | +API, which allows storing the desired state of Kubernetes clusters in OCI container registries. |
| 43 | + |
| 44 | +The `OCIRepository` v1 API comes with new features including: |
| 45 | + |
| 46 | +- Support for [Object-Level Workload Identity](#object-level-workload-identity), |
| 47 | + which allows Flux to use different cloud identities for accessing container registries on multi-tenant clusters. |
| 48 | +- Caching of registry credentials for cloud providers, which allows Flux to reuse the OIDC tokens |
| 49 | + for subsequent requests to the same registry, reducing the number of authentication requests. |
| 50 | + |
| 51 | +The `OCIRepository` v1 API is backward compatible with the previous v1beta2 API, users can upgrade |
| 52 | +by changing the `apiVersion` in the YAML files that contain `OCIRepository` definitions from |
| 53 | +`source.toolkit.fluxcd.io/v1beta2` to `source.toolkit.fluxcd.io/v1`. |
| 54 | + |
| 55 | +The Flux CLI commands for working with OCI artifacts have been promoted to stable: |
| 56 | + |
| 57 | +- `flux build artifact` |
| 58 | +- `flux push artifact` |
| 59 | +- `flux pull artifact` |
| 60 | +- `flux tag artifact` |
| 61 | +- `flux diff artifact` |
| 62 | +- `flux list artifacts` |
| 63 | + |
| 64 | +The Flux custom media types used for OCI artifacts produced by the Flux CLI are now stable: |
| 65 | + |
| 66 | +- config media type `application/vnd.cncf.flux.config.v1+json` |
| 67 | +- content media type `application/vnd.cncf.flux.content.v1.tar+gzip` |
| 68 | + |
| 69 | +## Image Automation Digest Pinning |
| 70 | + |
| 71 | +In Flux v2.6, the image automation has been enhanced to support digest pinning |
| 72 | +for container images. This feature allows users to configure the `ImagePolicy` |
| 73 | +to track the latest digest of a container image, and the `ImageUpdateAutomation` |
| 74 | +to update the manifests in the Git repository with the new digest. |
| 75 | + |
| 76 | +The `ImagePolicy` can now be configured to select the latest image digest |
| 77 | +with `.spec.digestReflectionPolicy` set to `Always`. |
| 78 | +Once a policy is set to track the latest digest, the manifests in the Git repository |
| 79 | +will be updated with digest references in the format `<registry>/<name>:<tag>@<digest>`. |
| 80 | + |
| 81 | +A new marker has been introduced to allow setting the digest in custom resources |
| 82 | +where `repository`, `tag` and `digest` are separate values: |
| 83 | + |
| 84 | +```yaml |
| 85 | +apiVersion: helm.toolkit.fluxcd.io/v2 |
| 86 | +kind: HelmRelease |
| 87 | +metadata: |
| 88 | + name: my-app |
| 89 | + namespace: apps |
| 90 | +spec: |
| 91 | + values: |
| 92 | + image: |
| 93 | + repository: docker.io/my-org/my-app # {"$imagepolicy": "flux-system:my-app:name"} |
| 94 | + tag: latest # {"$imagepolicy": "flux-system:my-app:tag"} |
| 95 | + digest: sha256:ec0119... # {"$imagepolicy": "flux-system:my-app:digest"} |
| 96 | +``` |
| 97 | +
|
| 98 | +For more details on how to configure image automation digest pinning, |
| 99 | +see the following [guide](/flux/guides/image-update/#digest-pinning). |
| 100 | +
|
| 101 | +## Object-level Workload Identity |
| 102 | +
|
| 103 | +Starting with Flux v2.6, you can configure workload identity at the object level |
| 104 | +in the `Kustomization` API for SOPS decryption with KMS services, and in the |
| 105 | +`OCIRepository` and `ImageRepository` APIs for accessing container registries. |
| 106 | + |
| 107 | +This feature allows cluster admins to use different cloud identities on multi-tenant |
| 108 | +clusters. Instead of relying on static Secrets that require manual rotation, |
| 109 | +you can now assign cloud identities per tenant by leveraging Kubernetes Workload Identity. |
| 110 | + |
| 111 | +To use this feature, cluster admins have to enable the feature gate |
| 112 | +`ObjectLevelWorkloadIdentity` which is opt-in from Flux v2.6. |
| 113 | + |
| 114 | +For more details on how to configure object-level workload identity for Flux, |
| 115 | +see the following docs: |
| 116 | + |
| 117 | +- [AWS workload identity](/flux/integrations/aws/) |
| 118 | +- [Azure workload identity](/flux/integrations/azure/) |
| 119 | +- [GCP workload identity](/flux/integrations/gcp/) |
| 120 | + |
| 121 | +### GitHub App Authentication |
| 122 | + |
| 123 | +In Flux v2.6, we have completed the integration of GitHub App authentication for Git repositories. |
| 124 | +This feature was introduced in [Flux v2.5](https://fluxcd.io/blog/2025/02/flux-v2.5.0/#github-app-authentication-for-git-repositories), |
| 125 | +and it is now fully supported across all Flux APIs. |
| 126 | + |
| 127 | +The GitHub App authentication tokens are now cached by the Flux controllers |
| 128 | +and reused for subsequent requests for the duration of the token lifetime. |
| 129 | + |
| 130 | +The notification-controller has also been updated to support GitHub App authentication |
| 131 | +when updating [Git commit statuses](/flux/components/notification/providers/#git-commit-status-updates) |
| 132 | +and for triggering [GitHub Actions workflows](flux/components/notification/providers/#github-dispatch). |
| 133 | + |
| 134 | +### Notifications Improvements |
| 135 | + |
| 136 | +Starting with Flux v2.6, users can customize the [Git commit status](/flux/components/notification/providers/#git-commit-status-updates) |
| 137 | +identifier in the notifications sent to Git providers by using Common Expression Language (CEL) expressions. |
| 138 | + |
| 139 | +```yaml |
| 140 | +apiVersion: notification.toolkit.fluxcd.io/v1beta3 |
| 141 | +kind: Provider |
| 142 | +metadata: |
| 143 | + name: github-status |
| 144 | + namespace: flux-system |
| 145 | +spec: |
| 146 | + type: github |
| 147 | + address: https://github.com/my-gh-org/my-gh-repo |
| 148 | + secretRef: |
| 149 | + name: github-app-auth |
| 150 | + commitStatusExpr: "(event.involvedObject.kind + '/' + event.involvedObject.name + '/' + event.metadata.clusterName)" |
| 151 | +``` |
| 152 | + |
| 153 | +Customizing the commit status ID is particularly useful when using a monorepo for a fleet of Kubernetes clusters, |
| 154 | +as it allows you to differentiate the commit statuses for each cluster. |
| 155 | + |
| 156 | +Other improvements include: |
| 157 | + |
| 158 | +- The notification-controller can now use Azure Workload Identity when sending notifications to Azure Event Hub. |
| 159 | +- The `github` and `githubdispatch` providers now support authenticating with a GitHub App. |
| 160 | + |
| 161 | +## Controller Improvements |
| 162 | + |
| 163 | +- The `GitRepository` v1 API now supports sparse checkout by setting a list of directories in the `.spec.sparseCheckout` field. |
| 164 | + This allows for optimizing the amount of data fetched from the Git repository. |
| 165 | +- The `GitRepository` v1 API gains supports mTLS authentication for HTTPS Git repositories. |
| 166 | +- The `Kustomization` v1 API now supports the value `WaitForTermination` for the `.spec.deletionPolicy` field. |
| 167 | + This instructs the controller to wait for the deletion of all resources managed by the Kustomization |
| 168 | + before allowing the Kustomization itself to be deleted. |
| 169 | +- The helm-controller v1.3.0 comes with a new feature gate called `DisableChartDigestTracking`, |
| 170 | + which allows disabling appending the digest of OCI Helm charts to the chart version. |
| 171 | + This is useful for charts that do not follow Helm's recommendation of using the app version |
| 172 | + instead of the chart version as a label in the manifests. |
| 173 | + |
| 174 | +## Supported Versions |
| 175 | + |
| 176 | +Flux v2.3 has reached end-of-life and is no longer supported. |
| 177 | + |
| 178 | +Flux v2.6 supports the following Kubernetes versions: |
| 179 | + |
| 180 | +| Distribution | Versions | |
| 181 | +|:-------------|:-----------------| |
| 182 | +| Kubernetes | 1.31, 1.32, 1.33 | |
| 183 | +| OpenShift | 4.18 | |
| 184 | + |
| 185 | +{{% alert color="info" title="Enterprise support" %}} |
| 186 | +Note that the CNCF Flux project offers support only for the latest |
| 187 | +three minor versions of Kubernetes. |
| 188 | + |
| 189 | +Backwards compatibility with older versions of Kubernetes and OpenShift is offered by vendors |
| 190 | +such as [ControlPlane](https://control-plane.io/enterprise-for-flux-cd/) that provide |
| 191 | +enterprise support for Flux. |
| 192 | +{{% /alert %}} |
| 193 | + |
| 194 | +## Over and out |
| 195 | + |
| 196 | +If you have any questions, or simply just like what you read and want to get involved, |
| 197 | +here are a few good ways to reach us: |
| 198 | + |
| 199 | +- Join our [upcoming dev meetings](https://fluxcd.io/community/#meetings). |
| 200 | +- Join the [Flux mailing list](https://lists.cncf.io/g/cncf-flux-dev) and let us know what you need help with. |
| 201 | +- Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/). |
| 202 | +- Join the [planning discussions](https://github.com/fluxcd/flux2/discussions). |
| 203 | +- Follow [Flux on Twitter](https://twitter.com/fluxcd), or join the |
| 204 | + [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). |
0 commit comments