Fix Azure CLI authentication for federated token service principals#1274
Conversation
| if !isMsi { | ||
|
|
||
| // 2. Service principal with client ID as name (likely federated token) | ||
| // When user.name is a GUID and user.type is servicePrincipal, it's often federated token auth |
There was a problem hiding this comment.
it's often federated token auth
What happens when it is not? Could we be introducing a breaking change for existing users?
There was a problem hiding this comment.
Are you talking about regular service principals that use GUID client IDs but sign in with a client secret (not federated tokens)? Since both look like GUIDs, this logic can’t really tell them apart.
If that’s the issue, I can change the flow: first try with --tenant (same as today), and if that fails for service principals, fall back to trying without it. WDYT?
There was a problem hiding this comment.
Are you talking about regular service principals that use GUID client IDs but sign in with a client secret (not federated tokens)? Since both look like GUIDs, this logic can’t really tell them apart.
Yes. I don't know if it can happen, but I am concerned of breaking any workflow which currently works.
If that’s the issue, I can change the flow: first try with --tenant (same as today), and if that fails for service principals, fall back to trying without it. WDYT?
That makes sense to me.
Reproduces issue where service principals authenticated via federated tokens are incorrectly identified as regular service principals, causing authentication failures when tenant ID is passed to az account get-access-token. This happens in AKS environments with workload identity where service principals have client IDs as names rather than systemAssignedIdentity or userAssignedIdentity. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Enhances MSI detection logic to recognize service principals with GUID-like names as federated token authentication, which should not use tenant ID parameters. This resolves authentication failures in AKS workload identity environments. The fix detects federated tokens by checking if account.User.Name matches the GUID pattern (8-4-4-4-12 format), treating them like MSI for token retrieval. This avoids tenant ID usage that causes auth failures. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Instead of detecting federated tokens via GUID patterns, use a more robust fallback mechanism: try with tenant ID first (preserving existing behavior), then retry without tenant ID if it fails for service principals. This addresses the concern that GUID detection cannot distinguish between regular service principals and federated token service principals, as both use client IDs as names. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
2 participants
What changes are proposed in this pull request?
WHAT: This PR enhances the Azure CLI authentication logic in the Databricks Go SDK to properly handle federated token service principals used in AKS workload identity scenarios.
The specific changes include:
config/auth_azure_cli.goto recognize service principals with GUID-like names as federated token authenticationisGuidLike()helper function to detect GUID patterns (8-4-4-4-12 character format)config/auth_azure_cli_federated_token_test.goWHY: The existing MSI detection logic only recognized system/user assigned identities by their specific names (
systemAssignedIdentityoruserAssignedIdentity). However, when using AKS with workload identity, service principals authenticate using federated tokens and show their client ID as the name (e.g.,5817e630-86b3-4f67-a38e-a63e6a1a401c).This caused the SDK to incorrectly treat federated token service principals as regular service principals, leading to:
--tenant <tenant_id>toaz account get-access-tokenThe decision to use GUID pattern detection was made because:
How is this tested?
Unit Tests:
TestAzureCliCredentials_FederatedTokenServicePrincipalwhich simulates the exact federated token scenario using the client ID pattern from the reported issueFAIL_IF_TENANT_ID_SET=trueenvironment variable to ensure the fix correctly skips tenant ID usage (test would fail if--tenantparameter was passed)Test Coverage Validation:
The test uses the existing mock infrastructure (
testdata/az) rather than custom mocks, ensuring consistency with other authentication tests.