Azure Workload Identity Support for Blob Storage

[toky-magentic]

Describe the feature or potential improvement

Problem

Self-hosting Langfuse on AKS currently requires static storage account access keys for Azure Blob Storage. This creates security concerns and doesn't align with Azure best practices for credential-less authentication.

Proposed Solution

Add support for Azure Workload Identity by integrating the native Azure SDK (@azure/storage-blob + @azure/identity).

When storageProvider: "azure" is set without explicit credentials, use DefaultAzureCredential to automatically pick up workload identity tokens—similar to how AWS S3 IAM roles work today.

Why This Matters

• Eliminates static credential management
• Aligns with Azure security best practices
• Matches existing AWS IAM role support
• Related: Add Google Cloud Storage support #6227 (GCS IAM support request)

Additional information

No response

[Steffen911]

@toky-magentic Thank you for the suggestion. I agree that this would be a useful addition and we're open for community contributions around this if we don't get to it quickly enough within the maintainer team.

[gayatriprasad]

Hello @Steffen911 ,

Adding a confirmation from the enterprise/regulated side, in case it's useful signal for prioritization.

We hit this exact gap in a production self-hosted deployment (v3.178.0, confirmed identical in v3.180.0 via source review of AzureBlobStorageService / StorageService.ts) — our storage account enforces KeyBasedAuthenticationNotPermitted as a non-negotiable security policy, which is increasingly the default posture for regulated-industry Azure environments, not an edge case. That makes the account-key requirement a hard blocker rather than an inconvenience: there's no key we're permitted to generate, full stop. We independently verified every other layer of the auth chain works correctly : a manual authenticated blob PUT using a live managed-identity token returned HTTP 201 - so the only missing piece is a DefaultAzureCredential / managed-identity code path in the blob service itself, exactly as described above.

Wanted to ask directly: is there a rough sense of timeline on the maintainer side, or would a community-contributed PR against this actually get reviewed and merged in reasonable time if we (or someone else) built it? Happy to contribute if that's the faster path - just want to gauge whether to invest engineering time here or route around it with an S3-compatible interim shim.

[Steffen911]

@gayatriprasad We'd be happy to accept contributions around this if they're targeted and don't significantly increase any maintenance burden. Just ping me in case you have something that should be reviewed.

[YuhongIsPro]

Opened a PR for this: #15596

It adds LANGFUSE_AZURE_BLOB_CREDENTIAL to pick the auth method — workload-identity, managed-identity, service-principal or default-chain — with shared-key staying the default, so existing deployments are unaffected. On the Azure AD paths, pre-signed URLs are signed with a user delegation key, which needs Storage Blob Data Contributor plus Storage Blob Delegator on the storage account.

I don't have an AKS cluster with key-based auth disabled, so that path is covered by unit tests only. @toky-magentic @gayatriprasad — if either of you can run the branch against a real setup, that's the one missing piece before this can be merged with confidence.

@Steffen911 — the PR is ready for review. CI hasn't run yet since fork PRs need a maintainer to approve the workflow run. There are also two design decisions in the PR description I'd rather you make than me.