[WIP] feat: default to kubelet identity when AzureStorageIdentityClientID is empty for MSI auth#2430
Conversation
…s empty for MSI auth When AzureStorageAuthType is set to MSI but AzureStorageIdentityClientID is not specified, the driver now defaults to the kubelet identity (UserAssignedIdentityID from cloud config). If the kubelet identity is also not available, the driver returns a clear error instead of silently proceeding and failing at mount time.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andyzhangx The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
Adds stricter MSI-auth identity selection in GetAuthEnv to improve failure clarity when an identity isn’t explicitly provided, aligning behavior with a “default to kubelet identity” expectation in AKS-style setups.
Changes:
- Default MSI mounts to
UserAssignedIdentityIDfrom cloud config when noAZURE_STORAGE_IDENTITY_*env is already set. - Return an early, clearer error when MSI is selected but neither an explicit identity nor a kubelet identity is available.
- Add unit tests covering the new defaulting and error behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| pkg/blob/blob.go | Changes MSI auth env construction: default to kubelet identity or return a clearer error when missing. |
| pkg/blob/blob_test.go | Adds tests validating kubelet-identity defaulting and the new “no identity available” error. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ead of error for IMDS fallback
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if strings.EqualFold(azureStorageAuthType, storageAuthTypeMSI) { | ||
| // check whether authEnv contains a non-empty AZURE_STORAGE_IDENTITY_ value | ||
| containsIdentityEnv := false |
There was a problem hiding this comment.
azureStorageAuthType is compared using == storageAuthTypeMSI, but docs/examples commonly set AzureStorageAuthType: MSI (uppercase). This means the MSI-specific identity defaulting/error path won’t run for those values. Use strings.EqualFold(azureStorageAuthType, storageAuthTypeMSI) here (consistent with the earlier secret-handling check) and add/adjust a unit test to cover uppercase MSI.
| if !containsIdentityEnv { | ||
| if d.cloud != nil && d.cloud.Config.AzureAuthConfig.UserAssignedIdentityID != "" { | ||
| klog.V(2).Infof("MSI auth: AzureStorageIdentityClientID not specified, default to kubelet identity (%s)", | ||
| d.cloud.Config.AzureAuthConfig.UserAssignedIdentityID) |
There was a problem hiding this comment.
This change makes MSI auth fail fast when neither AzureStorageIdentityClientID nor cloud.Config.AzureAuthConfig.UserAssignedIdentityID is set. That can be a breaking behavior change for clusters that rely on system-assigned MSI/IMDS (where omitting the client ID can still be valid). If the intention is to preserve IMDS fallback, consider logging a warning and continuing instead of returning an error; otherwise, please update the public docs/parameters to reflect that an identity client ID (explicit or kubelet) is now required for AzureStorageAuthType=MSI.
| _, _, _, _, _, err := d.GetAuthEnv(context.TODO(), volumeID, "", attrib, secret) //nolint:dogsled | ||
| assert.NoError(t, err) // should not error, falls back to IMDS | ||
| } | ||
|
|
There was a problem hiding this comment.
The new MSI defaulting behavior isn’t covered for two important inputs that occur in docs/config: (1) AzureStorageAuthType: MSI (uppercase), and (2) AzureStorageIdentityClientID present but empty/whitespace. Adding targeted unit tests for these cases will prevent regressions and will catch the current case-sensitivity/empty-value pitfalls.
| func TestGetAuthEnvMSIDefaultsToKubeletIdentityWhenClientIDWhitespace(t *testing.T) { | |
| d := NewFakeDriver() | |
| d.cloud = &storage.AccountRepo{} | |
| d.cloud.Config.AzureAuthConfig = azclient.AzureAuthConfig{ | |
| UserAssignedIdentityID: "kubelet-identity-client-id", | |
| } | |
| attrib := map[string]string{ | |
| containerNameField: "containername", | |
| storageAccountField: "accountname", | |
| storageAuthTypeField: storageAuthTypeMSI, | |
| storageIdentityClientIDField: " ", | |
| } | |
| secret := map[string]string{ | |
| accountNameField: "accountname", | |
| accountKeyField: "testkey", | |
| } | |
| volumeID := "rg#accountname#containername" | |
| _, _, _, _, authEnv, err := d.GetAuthEnv(context.TODO(), volumeID, "", attrib, secret) //nolint:dogsled | |
| assert.NoError(t, err) | |
| found := false | |
| for _, env := range authEnv { | |
| if env == "AZURE_STORAGE_IDENTITY_CLIENT_ID=kubelet-identity-client-id" { | |
| found = true | |
| break | |
| } | |
| } | |
| assert.True(t, found, "Should default to kubelet identity when AzureStorageIdentityClientID is empty or whitespace") | |
| } |
|
/retest |
1 similar comment
|
/retest |
What type of PR is this?
/kind feature
What this PR does / why we need it:
When
AzureStorageAuthTypeis set toMSIbutAzureStorageIdentityClientIDis not specified, the driver now:UserAssignedIdentityIDfrom cloud config) — this is the built-in managed identity bound to the AKS agent node pool (named{cluster-name}-agentpool)This improves the user experience for the common case where users set
AzureStorageAuthType: MSIin their PV/StorageClass but forget to specify the identity client ID — the driver will automatically use the kubelet identity if available.How does this PR make you feel?
Less cryptic mount failures 🎉
Does this PR introduce a user-facing change?