Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for a new concept in duckdb: secrets (duckdb/duckdb#10042)
To summarize, secrets are, in the most generic sense, scoped sets of configuration that provide the necessary information to do something. In most cases this "something" will be an authorized request to some API.
For the Azure extension this means the what was previously configured through duckdb settings, will now be done through secrets.
Added secret providers
This PR adds the
azure
secret type with 2 secret providers:config
andcredential_chain
Config provider
the
config
provider is the default provider for azure secrets. It can be used in two ways:Firstly it can be used to specify an account name for public accessible azure storage urls:
Secondly, it can be used with the CONNECTION_STRING param to query from authenticated places:
credential_chain provider
The
credential_chain
azure secret provider can be used similar to what is being added in the aws extension now as well duckdb/duckdb_aws#23. Basically it allows to either just use the default Azure SDK credential chain, or specify a custom chain.To create a secret that uses the default credential chain:
Or to specify to only use the CLI and env providers, in that order:
Note: CI is still a bit of a work in progress here, some things are testable only manually ATM, I leave that to future work