feat(aso): add azure workload identity label to pod template

[synthe102]

What type of PR is this?

/kind feature
What this PR does / why we need it:

Add the label azure.workload.identity/use: "true" to ASO deployment pod template so credentials can be injected using the Azure Workload Identity webhook.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

• cherry-pick candidate

TODOs:

• squashed commits
• includes documentation
• adds unit tests

Release note:

[k8s-ci-robot]

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign fabriziopandini for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @synthe102!

It looks like this is your first PR to kubernetes-sigs/cluster-api-provider-azure 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/cluster-api-provider-azure has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @synthe102. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1ce44f1) 61.95% compared to head (3536e26) 61.96%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4452      +/-   ##
==========================================
+ Coverage   61.95%   61.96%   +0.01%     
==========================================
  Files         188      188              
  Lines       18768    18768              
==========================================
+ Hits        11628    11630       +2     
+ Misses       6502     6500       -2     
  Partials      638      638              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mboersma]

/ok-to-test

[nojnhuh]

@mattchr Is this not needed per your point here or was that a separate issue? #3113 (comment)

[synthe102]

It's needed if you want to leverage the Azure WI webhook to inject the creds based on your service account. I think that if capz-manager has this annotation, there's no reason to keep it from being added to ASO for consistency reasons.

[nojnhuh]

Sorry, wrong Matt. @matthchr

[matthchr]

there's no reason to keep it from being added to ASO for consistency reasons.

This is true, but at the same time there is no reason to add it because it won't do anything for ASO. ASO doesn't need or use the WI webhook because it creates the credential without going to IMDS, which means it doesn't use the WI webhook at all.

Instead it uses the USE_WORKLOAD_IDENTITY_AUTH boolean for the global secret, or AUTH_MODE: "workloadidentity" for the aso-credential or per-resource secrets.

The reason we don't use the webhook is that the webhook is based on env variables in the pod, but because the pod is multitenant (can be using multiple identities 1 per namespace or 1 per resource even) the webhook doesn't really help us.

[nojnhuh]

Instead it uses the USE_WORKLOAD_IDENTITY_AUTH boolean for the global secret, or AUTH_MODE: "workloadidentity" for the aso-credential or per-resource secrets.

And CAPZ should configure this automatically for you based on the AzureClusterIdentity for the cluster.

[synthe102]

Thanks for all this context ! It makes sense. I can close this PR as it's not needed.