feat(azure_blob sink): Expand support for Azure authentication types

[jlaundry]

Summary

As mentioned in #24492 (comment), now that #22912 has landed, we can make the AzureAuthentication config generic, so that the other Azure authentication types can be re-supported by azure_blob (and eventually azure_data_explorer #24633, and azure_event_hub #24659).

This currently includes Azure CLI, Managed Identity, Workload Identity, as well as a special chained Managed Identity Client Assertion. I'm happy to add others that people believe they have a use-case for, I just didn't want to add code that was unlikely to be used.

Todo list

• Migrate existing AzureAuthentication config type
• Add additional requested authentication types
  • ClientCertificateCredential: feat(azure_blob sink): Expand support for Azure authentication types #24729 (comment)
• Remove block_in_place (int tests fail with thread 'sinks::azure_blob::test::azure_blob_build_config_with_client_id_and_secret' (1977) panicked at src/sinks/azure_common/config.rs:380:43: can call blocking only when running on the multi-threaded runtime)
• Integration tests with Azurite and real and Mock tokens

Vector configuration

For example:

sinks:
  blob:
    type: azure_blob
    inputs:
      - stdin

    connection_string: AccountName=teststorage
    container_name: vectorlogs

    encoding:
      codec: json
      json:
        pretty: true

    auth:
      azure_client_id: ${AZURE_CLIENT_ID}
      azure_client_secret: ${AZURE_CLIENT_SECRET}
      azure_tenant_id: ${AZURE_TENANT_ID}

How did you test this PR?

Currently testing in my lab environment; I've got WIP for running the integration test suite, but it's failing to pick up the integration test CA (#24729 (review))

Change Type

• Bug fix
• New feature
• Dependencies
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the no-changelog label to this PR.

References

• Closes: Enhance Azure Identity Integration in Vector: Ability to Utilize Passwordless Connections #20625
• Closes: Support Azure Active Directory tokens for the Azure Blob Store Sink #24167
• Closes: Vector versions >= 0.50.0 no longer support Azure token auth via environment variables #24491
• Closes: fix(azure_blob sink): Re-add support for Azure token auth via environment variables #24492
• Closes: fix(azure_blob sink): restore non-connection string auth #24624
• Related: feat(new sink): Azure Data Explorer Sink #24633
• Related: feat(new source/sink) Added Azure Event Hub source/sink #24659

Notes

• Please read our Vector contributor resources.
• Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
• Some CI checks run only after we manually approve them.
  • We recommend adding a pre-push hook, please see this template.
  • Alternatively, we recommend running the following locally before pushing to the remote branch:
    • make fmt
    • make check-clippy (if there are failures it's possible some of them can be fixed with make clippy-fix)
    • make test
• After a review is requested, please avoid force pushes to help us review incrementally.
  • Feel free to push as many commits as you want. They will be squashed into one before merging.
  • For example, you can run git merge origin master and git push.
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run make build-licenses to regenerate the license inventory and commit the changes (if any). More details here.

[LarryOsterman]

You might consider updating to the current (february) Azure SDK. The only iffy part of that is that it brings a dependency on reqwest version 13, not 12.

[jlaundry]

Am I right in thinking that 0.33 is imminent? I was thinking of waiting for Azure/azure-sdk-for-rust#3643 and Azure/azure-sdk-for-rust#3807

[LarryOsterman]

0.33 should be out in a day or so - the big change in 0.33 is removing support for wasm, the rest are relatively minor changes.

However I don't know what the timeline is for the corresponding storage releases. And until we GA the azure SDK, all the SDK client packages are tied at the hip - they all need to be re-released. After GA, we will have a somewhat looser coupling between azure_core and the other crates.

[LarryOsterman]

Ok, it turns out I was mistaken. azure_core 0.33 is out now. So it's available but the corresponding storage is not quite.

[jlaundry]

Looks like azure_storage_blob@0.10.0 just dropped

[LarryOsterman]

Yup, sorry I forgot to mention it to you - yesterday was a bit chaotic (for the storage team as well - they had to make some last minute changes to make the March release).

[jlaundry]

No worries 🙂

I've pushed the change on a separate branch (jlaundry/vector@feature-azure_auth...jlaundry:vector:update-azure-crates-0.33), and the update caused the integration tests to fail:

"400: <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Error>\n <Code>InvalidHeaderValue</Code>\n <Message>The API version 2026-04-06 is not supported by Azurite. Please upgrade Azurite to latest version and retry. If you are using Azurite in Visual Studio, please check you have installed latest Visual Studio patch. Azurite command line parameter \"--skipApiVersionCheck\" or Visual Studio Code configuration \"Skip Api Version Check\" can skip this error. \nRequestId:70cc1270-db0c-4e13-ba15-41f3eca1352e\nTime:2026-03-12T20:02:13.682Z</Message>\n</Error>

Related: Azure/Azurite#2623

Adding --skipApiVersionCheck to the docker-compose file works (at least, the tests pass...)

@thomasqueirozb are you happy if I pull these updates into this PR, or would you prefer to have a separate one right after?

[LarryOsterman]

FWIW, Azurite has a --ignore-api-version switch (or something like that - I don't remember what exactly it is) which I ended up having to use in my testing.

[jlaundry]

.

[zapdos26]

Hey @jlaundry thanks for doing this! Would be possible to add ClientCertificateCredential as well? We would certainly use it!

[jlaundry]

I think we're ready to progress this PR further - thanks again to @LarryOsterman for the nits, and the conversation earlier today!

A few notes:

• You'll see I changed the Default for AzureAuthentication - I note that if v0.54.0 is released before this PR merges, it technically becomes a breaking change, as azure_logs_ingestion will require the auth.azure_credential_kind to be set when using ClientSecretCredentials... I'm hoping we can squeeze this in 😄
• I wanted to move src/sinks/azure_common/service.rs, sink.rs, and L307-L575 of config.rs into azure_blob, because it's not really "common"... but that makes it more difficult to read this PR, so I'll leave that for once this lands.
• I'd like some feedback on the tls config option (see comment above). It makes sense to support having an enterprise CA for TLS MiTM scenarios and re-use the wider TlsConfig, but reqwest_12 doesn't really allow most of the options to be implemented without substantial plumbing, and I'm not really happy with Err'ing out all the other options. I tried to look for conventions:
  • amqp just ignores unsupported attributes (which has related issues)
  • greptimedb was the only one I could find that explicitly Err'd out unsupported config
  • pulsar defines it's own struct, with the same names and documentation strings - this is ultimately the option I landed on

[Clee2691]

@jlaundry I've been following the Logs Ingestion sink implementation and it is really great work!

One request here for authentication is to allow passing in options for Azure's WorkloadIdentityCredential type so that it doesn't just rely on environment variables but can fall back onto env variables if no options are provided. It's a relatively small change and I was going to make a PR for it but I see that Azure auth is being worked on further.

[jlaundry]

One request here for authentication is to allow passing in options for Azure's WorkloadIdentityCredential type so that it doesn't just rely on environment variables but can fall back onto env variables if no options are provided. It's a relatively small change and I was going to make a PR for it but I see that Azure auth is being worked on further.

Easy, done :)

I don't have any easy way to test, @Clee2691 could you please compile and check it in your environment?

One thing to note is that I've called these options client_id (instead of azure_client_id in Client*Credential), because I found that the generated docs don't seem to like having the same option required in some relevant_when but not in others...

[Clee2691]

One request here for authentication is to allow passing in options for Azure's WorkloadIdentityCredential type so that it doesn't just rely on environment variables but can fall back onto env variables if no options are provided. It's a relatively small change and I was going to make a PR for it but I see that Azure auth is being worked on further.

Easy, done :)

I don't have any easy way to test, @Clee2691 could you please compile and check it in your environment?

One thing to note is that I've called these options client_id (instead of azure_client_id in Client*Credential), because I found that the generated docs don't seem to like having the same option required in some relevant_when but not in others...

This works. This is also how I had it implemented before your changes.