@pjbgf Thank you very much for the review!

multi-tenancy is a charged term, so it is quite important to define what precisely we mean by that and what guarantees we are providing as part of this RFC.
My take is that this supports out-of-the-box the multiple teams model. The multiple customers model is achievable, but requires stronger security boundaries at cluster topology level - for coping with more hostile environment.

Agreed! Added a section to clarify this on the beginning 👍

The cache keys format, so that it is crystal clear that it will be resistant to cross-tenant takeovers. As you already pointed out, when sharing the same cache storage, the cache key will require some level of tenant or object level information to provide isolation. What in the format picked will result in a malicious tenant not being able to forge it (e.g. the fully qualified service account name plus x, y and z)?

Format added 👍 And specifically about:

What in the format picked will result in a malicious tenant not being able to forge it (e.g. the fully qualified service account name plus x, y and z)?

In the Cache Key section, the five paragraphs following the list of components are there to justify the presence of each component, be it for preventing malicious tenants from forging/stealing tokens from other tenants, or for making sure that served tokens are according to the request specifications and hence will be valid for the use case in question. I added a ##### Justification header on the beginning of these paragraphs to make it clearer.

What security controls are in place (or can be implemented by the user) to ensure that even if tenant A knows the Cloud Provider annotations for tenant B, it won't be able to impersonate them.
This can be as simple as they enforcing rules via Admission Controllers (e.g. Kubewarden), as per some examples of Flux multi-tenancy. Or something more sophisticated as part of the new feature.

Great point, there's a paragraph in the Technical Background section pointing out how this works. This is inherently built into the workload identity features of each cloud provider, you must create a strong link between the Kubernetes ServiceAccount and the cloud provider identity by granting impersonation permission to the latter on the former, see the original paragraph I wrote:

Another aspect of workload identity that is important for this RFC is how the cloud identities are associated with the Kubernetes ServiceAccounts. In most cases, an identity from the IAM service of the cloud provider (e.g. a GCP IAM Service Account, or an AWS IAM Role) is associated with a Kubernetes ServiceAccount by the process of impersonation. Permission to impersonate the cloud identity is granted to the ServiceAccount.

Here's the updated paragraph with a bit more details at the end:

Another aspect of workload identity that is important for this RFC is how the cloud
identities are associated with the Kubernetes ServiceAccounts. In most cases, an
identity from the IAM service of the cloud provider (e.g. a GCP IAM Service Account,
or an AWS IAM Role) is associated with a Kubernetes ServiceAccount by the process
of impersonation. Permission to impersonate the cloud identity is granted to the
ServiceAccount through a configuration that points to the fully qualified name of
the Kubernetes ServiceAccount, i.e. the name and namespace of the ServiceAccount
and which cluster it belongs to in the name/address system of the cloud provider.

So essentially the identities are not secret, knowing what cloud identity a tenant uses gives no advantages to a malicious neighbor tenant whatsoever.

The limitations of this feature for multi-tenancy in hostile environments where the tenants are not trustworthy. Suggestions on how to overcome them is optional, as that can be a larger topic - e.g. stronger isolation so that tenants can't impersonate each other's identities even if they know them and can bypass controls that may be operating at a degraded state (i.e. admission controllers).

As discussed right above, no admission controllers are required, the impersonation permission is implemented and enforced by the cloud provider. You grant impersonation permission for ServiceAccount A to impersonate cloud identity X at the cloud provider level. The ServiceAccount B will never be able to impersonate cloud identity X if you don't give it the same permission. The model here is zero trust, ServiceAccount B has no impersonation permissions by default.

Workload identity is pretty solid :)

New SOPS version 3.10.0 released with the GCP KMS oauth2.TokenSource authentication method and already bumped in kustomize-controller:

fluxcd/kustomize-controller#1410

I'm now addressing the offline comments I got during KubeCon EU 2025.

From @stealthybox:

An alternative to using service account tokens would be using a token whose subject string encodes a direct reference to the respective Flux resource, this way a resource would be its own identity. This is more secure than having a configuration knob to define another resource (a service account in this case) as the object identity, as it prevents another object in the same namespace from abusing the same service account/cloud permissions.

From @hiddeco:

We should move the interfaces in interfaces.go to multiple files with names matching the interface names themselves.

From @stefanprodan:

To avoid introducing kustomizations.spec.decryption.key.serviceAccountName for disambiguating single-tenant and multi-tenant workload identity we should instead introduce a binary flag in the controllers to switch to and enforce multi-tenant workload identity, e.g. --require-service-account-for-provider-auth

@stealthybox @hiddeco @stefanprodan Comments from KubeCon addressed, please feel free to do another pass/approve.