Skip to content

fix: 320 azure workload identity authentication#321

Open
MCBoarder289 wants to merge 2 commits into
duckdb:mainfrom
MCBoarder289:fix/320-azure-workload-identity
Open

fix: 320 azure workload identity authentication#321
MCBoarder289 wants to merge 2 commits into
duckdb:mainfrom
MCBoarder289:fix/320-azure-workload-identity

Conversation

@MCBoarder289

Copy link
Copy Markdown

This is a proposed PR to fix #320. I have tested this locally with an AKS cluster with a federated workload identity.

Please let me know if you have any feedback!

I also figure the test I tried to add won't run because I'm not familiar with your CI/CD setup. Hopefully it's useful, but definitely open to any adjustments there.

When reading delta tables from ADLS via workload_identity (commonly in
k8s), DuckDB's credential chain isn't passed through to delta-kernel's
credential resolution path, causing incorrect resolution.

This change passes workload_identity variables to delta-kernel's
expected options so that resolve_credential_auto() correctly leverages
the workload_identity path.

Fixes duckdb#320
Adds test/sql/cloud/azure/workload_identity_auth.test following the
same pattern as cli_auth.test and spn_auth.test.

The test is guarded by require-env on AZURE_CLIENT_ID, AZURE_TENANT_ID,
AZURE_FEDERATED_TOKEN_FILE, and AZURE_STORAGE_ACCOUNT — it will skip
silently in all existing CI pipelines (Azurite, cloud SPN-based) since
none provide a federated token environment.

Included to document expected behavior and provide coverage if an
AKS-based CI runner with workload identity is added in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

delta_scan silently ignores workload_identity in Azure credential chain, falls back to IMDS

1 participant