From e979df122a0239b4265e164d40b0280f1e996738 Mon Sep 17 00:00:00 2001 From: Matheus Pimenta Date: Thu, 15 May 2025 15:15:12 +0100 Subject: [PATCH] [RFC-0010] Update RFC to include opt-in feature gate Signed-off-by: Matheus Pimenta --- rfcs/0010-multi-tenant-workload-identity/README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/rfcs/0010-multi-tenant-workload-identity/README.md b/rfcs/0010-multi-tenant-workload-identity/README.md index c8e4a510..d975980f 100644 --- a/rfcs/0010-multi-tenant-workload-identity/README.md +++ b/rfcs/0010-multi-tenant-workload-identity/README.md @@ -565,7 +565,7 @@ the Flux APIs is to associate the Flux objects with Kubernetes `ServiceAccounts` We propose building the `ServiceAccount` token creation and exchange logic into the Flux controllers through a library in the `github.com/fluxcd/pkg` repository. -### API Changes +### API Changes and Feature Gates For all the Flux APIs interacting with cloud providers (except `Kustomization`, see the paragraph below), we propose introducing the field `spec.serviceAccountName` @@ -597,6 +597,16 @@ the cloud provider in the `Kustomization` API is detected by the SOPS SDK itself while decrypting the secrets, so we don't need to introduce a new field for this purpose. +To enable using the new `serviceAccountName` fields, we propose introducing +a feature gate called `ObjectLevelWorkloadIdentity` in the controllers that +would support the feature. In the first release we should make it opt-in so +cluster admins can consciously roll it out. If the feature gate is disabled +and users set the field in Flux APIs that use the field only for this feature, +a terminal error should be returned. If the feature gate is disabled and users +set the field in Flux APIs that use the field for other purposes, like in the +case of the `OCIRepository` and `ImageRepository` APIs, the controller should +just log a warning and ignore the field. + ### Workload Identity Library We propose using the Go package `github.com/fluxcd/pkg/auth`