Azure Workload Identity no longer working

[tomberget]

Describe the bug
ReplicationDestination and ReplicationSource no longer auto picks up the correct information for Azure Workload Identity. It seems #1934 broke it.

At least for the ReplicationSource, this worked in 0.15.0. In 0.16.0, manually trying to restore from backup, it is now broken.

Steps to reproduce
Set up Azure Workload Identity. Create a service account with federated credentials, and contributor access to a storage account. Make sure the service account is annotated with the manage identity client id.
Set the ReplicationSource/Destination moverServiceAccount to the service account. Use the federated service account. Set moverPodLabels: azure.workload.identity/use: "true"

Expected behavior
AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_FEDERATED_TOKEN_FILE are all defined as env:. No more magic is necessary.

Actual results
I tries loading these from a secret.

Additional context
When workload identity is enabled, you should not need to do anything else. All necessary secrets are already loaded and defined as the platform intends.

[tomberget]

It seems that the only thing missing is that the envFromSecret is made conditionally, based on the items in the secret - that way it should be able to work both with an existing secret (where these keys are present), and by the "normal" way of using workload identity - having the platform wire everything, so that these keys are present by automation.

[tesshuflower]

@tomberget thanks for this, I'm actually not familiar with the Azure workflow - are you saying that Azure itself will inject the env vars such as AZURE_TENANT_ID when you label the mover pod with azure.workload.identity/use: "true" - and so we're now interfering with those?

[tomberget]

@tesshuflower sorry for the late reply! Yes, all the env vars listed in #1934 are auto-injected when you set the moverPodLabel: as long as the service account used in moverServiceAccount has the annotation azure.workload.identity/client-id: xxxxxxxx-....-xxxxxxxxxxx.

Since you are forcing these env vars from a secret instead, the auto-injected ones are rendered useless :(

It actually works exactly like it should in 0.15.0.

[tesshuflower]

@tomberget thanks for this extra information, and sorry about the breakage - will look into setting those env var overrides from the secret only if they're actually set in the secret itself.