Azure
Improve single-operator multitenancy credential management for Workload Identity
Describe the current behavior
For workload identity in particular, if the user was able to discover the credential details (clientID/etc) via the Azure API and create their own copy of the secret in their namespace, they can use that secret because the FederatedIdentityCredential is for system:serviceaccount:azure-service-operator:azureserviceoperator-default.
Describe the improvement
I think we may be able to harden the single-operator multitenancy against this case by optionally allowing serviceaccount impersonation and allowing you to configure ASO such that it doesn't use its own SA directly to token-exchange with Azure, instead it impersonates a configured SA in the target namespace and uses that SA token -- would need to do more investigation into how exactly this would all work though.
What is the ETA on this? The current implementation of how the workload identity authentication scope works is not acceptable to use from a security perspective where the cluster is shared between different teams.
Ping from my side, too. This is really a security concern and an relatively easy privilege escalation.
