OCPBUGS-74245: azure: retrieve system-assigned identity client ID from IMDS

[patrickdillon]

When using a system-assigned managed identity (no ClientID in credentials), query IMDS to retrieve the identity's client ID and populate it in the session credentials. This ensures the CAPZ AzureClusterIdentity manifest has a populated ClientID, working around a CAPZ bug where an empty ClientID with type UserAssignedMSI causes the Azure SDK to reject the credential.

This is a workaround solution to the fix suggested in kubernetes-sigs/cluster-api-provider-azure#6152

Fixes OCPBUGS-74245

[openshift-ci-robot]

@patrickdillon: This pull request references Jira Issue OCPBUGS-74245, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.22.0) matches configured target version for branch (4.22.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @jinyunma

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

When using a system-assigned managed identity (no ClientID in credentials), query IMDS to retrieve the identity's client ID and populate it in the session credentials. This ensures the CAPZ AzureClusterIdentity manifest has a populated ClientID, working around a CAPZ bug where an empty ClientID with type UserAssignedMSI causes the Azure SDK to reject the credential.

This is a workaround solution to the fix suggested in kubernetes-sigs/cluster-api-provider-azure#6152

Fixes OCPBUGS-74245

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 openshift-eng/jira-lifecycle-plugin repository.

[patrickdillon]

/hold
I'm not sure we want to do this. This would be useful for backporting, but on the other hand, I'm not sure any users are actually complaining. My vote would be to wait for the upstream fix, but let's see if this works.

[openshift-ci]

[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 sadasu for approval. For more information see the 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:

• pkg/asset/installconfig/azure/OWNERS

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

[openshift-ci]

@patrickdillon: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-azure-ovn	62395f9	link	true	/test e2e-azure-ovn
ci/prow/golint	62395f9	link	true	/test golint
ci/prow/e2e-azurestack	62395f9	link	false	/test e2e-azurestack

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

[jinyunma]

/payload-job periodic-ci-openshift-verification-tests-main-installation-nightly-4.22-azure-ipi-oidc-managed-identity-system-f14

[openshift-ci]

@jinyunma: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

• periodic-ci-openshift-verification-tests-main-installation-nightly-4.22-azure-ipi-oidc-managed-identity-system-f14

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/876a4dd0-1b5f-11f1-9b9a-c6278760820f-0

[jinyunma]

but let's see if this works.

@patrickdillon Due to bug OCPBUGS-77845, payload job could not be launched directly in the PR, so I tested locally(removed unexpected credential request file during generating secret files), built payload with #10367, #10368, #9851 in cluster-bot, installed cluster with system-managed identity auth manually, and installation is successful.

FYI, even without this PR, another workaround is to set clientId of system-managed identity attached on VM in osServicePrincipal.json, then we can get successful installation in such case.