Enable workload identity on workload clusters

[CecileRobertMichon]

/kind feature

Describe the solution you'd like [A clear and concise description of what you want to happen.]

Today we allow users to configure workload identity on management clusters to be used by CAPZ to authenticate to Azure. The next step would be to automate configuring workload identity on workload clusters so it can be used by critical cluster components such as cloud-provider-azure.

Steps:

• Enable cluster for workload identity
  • Create a storage account
  • Upload 2 documents: discovery doc and JWKS (public signing key) to storage account
  • Configure issuer URL in apiserver flags (need to figure out how to do this? Maybe make it deterministic? or read the URL from the user defined url)
• Add the right FIC for cloud-provider to use (and storage drivers?)
• Configure cloud-provider-azure to use Workload Identity

Notes:

• If the issuer URL changes it might cause some pain to application developers
• There should be a way to rotate the secret in the storage account
• Users should use their own identity for workloads deployed to the cluster, NOT the cluster wide identity CAPZ creates for critical components

Environment:

• cluster-api-provider-azure version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[dtzar]

Recommend we close this with some reference comment with #4763

[jackfrancis]

I think the part about configuring cloud-provider-azure is still TODO. We could change the title to reflect that specific need and put this on the backlog.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten