Key Vault for secrets, keys and certificates
Implement and manage secrets, keys, and certificates by using Azure Key Vault
Three object types, three purposes
| Object | Holds | Typical use |
|---|---|---|
| Secret | Any value up to 25 KB | Connection strings, API keys, passwords |
| Key | A cryptographic key that never leaves the vault | Signing, encryption — the vault performs the operation |
| Certificate | An X.509 certificate with its private key | TLS, client authentication |
The distinction that matters: a secret is retrieved by the caller; a key is used inside the vault. If a scenario requires that private key material never be exposed to the application, the answer is a key with vault-side operations, not a secret containing key material.
Reaching the vault from a pipeline
Two supported routes:
- Key Vault-linked variable group — variables in the group are backed by vault secrets, so the vault remains the system of record.
- The Azure Key Vault task — fetches secrets at run time into the job.
Either way, authenticate with a managed identity or a workload-identity-federated service connection, so no credential is stored to reach the credential store.
Rotation and access
Rotation is the reason for centralisation: change the value in the vault and every consumer picks it up, with no pipeline edit. Access should be granted to the identity, least-privilege, and audited — vault access logs are the record of who read which secret when.
Primary sources