CAPZ isn't compatible within a vcluster, with workload identity enabled on AKS.

[mjnovice]

/kind bug

[Before submitting an issue, have you checked the Troubleshooting Guide?]

What steps did you take and what happened: [A clear and concise description of what the bug is.] Installed capz onto vcluster we see a clash in the volumes section

the pod section for pod created on host cluster, what vcluster will create it the following

  - name: azure-identity-token
    projected:
      defaultMode: 420
      sources:
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.annotations['vcluster.loft.sh/token-lkyoezps']
            mode: 420
            path: azure-identity-token

Pod creation on the host cluster fails because of

controller-manager-5bd448b8b4-gt44q                           Error syncing to physical cluster: Pod "capz-controller-manager-5bd448b8b4-gt44q-x-capz-syst-d6ecd524ea" is invalid: spec.volumes[3].name: Duplicate value: "azure-identity-token"

If we use --sync-label for vcluster to sync the label azure.workload.identity/use the workload identity webhook will try to add it, as the volumes section https://github.com/Azure/azure-workload-identity/blame/main/pkg/webhook/webhook.go#L401 are not the same, and the webhook tries to create it again.

What did you expect to happen: CAPZ pod doesn't come up

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

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

[JRBANCEL]

The azure-identity-token volume shouldn't be part of the Pod spec. Only specify the azure.workload.identity/use: "true" label should be specified and let the Workload Identity do its work.

[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

[nawazkh]

/remove-lifecycle stale