Managing Secrets and Secretless Authentication

What it is

Pipelines need access to things that must stay private: passwords, API keys, certificates, signing keys. A secrets strategy decides where they live, how pipelines get them, who can read them and how to avoid leaks. The strongest strategy is secretless: nothing is stored, because the pipeline proves its identity with a short lived token instead.

How it works

Azure Key Vault

Azure Key Vault stores secrets, keys and certificates with access control and auditing.

Ways pipelines use it:

• Azure Pipelines: the AzureKeyVault@2 task fetches chosen secrets into masked variables. A variable group linked to Key Vault does the same without a task. The service connection identity needs permission to get and list secrets.
• GitHub Actions: sign in with azure/login, then read the secret with the Azure CLI (az keyvault secret show), keeping it masked.
• Applications at run time: App Service and Functions can use Key Vault references in app settings, written as @Microsoft.KeyVault(SecretUri=...), and read through the app's managed identity. No secret is in the pipeline at all.

- task: AzureKeyVault@2
  inputs:
    azureSubscription: my-connection
    KeyVaultName: kv-prod-shop
    SecretsFilter: 'DbPassword,ApiKey'
    RunAsPreJob: false

Secretless authentication with OpenID Connect

Workload identity federation lets a pipeline exchange the token issued by the CI system for an Azure access token. Azure trusts the CI system's issuer and checks the subject claim, so no client secret is stored.

permissions:
  id-token: write
  contents: read
steps:
- uses: azure/login@v2
  with:
    client-id: ${{ vars.AZURE_CLIENT_ID }}
    tenant-id: ${{ vars.AZURE_TENANT_ID }}
    subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

Benefits: nothing to store, rotate or leak; tokens are short lived; and the subject lets you say "only the production environment of this repository" can sign in.

Secure files and sensitive files during deployment

Secure files in the Azure Pipelines Library store certificates, SSH keys and signing profiles encrypted. A pipeline downloads one with DownloadSecureFile@1, the file exists only for that job, and you can add approvals and checks and limit which pipelines may use it. In GitHub store small files as secrets (for example Base64 encoded) or, better, fetch them from Key Vault at deploy time. Delete the file when the job finishes and never write it into the artifact.

Preventing leakage

Store secrets at the narrowest scope: environment secrets (available only to jobs that target that environment and pass its rules) are better than repository secrets, which are better than organization secrets. In Azure DevOps use variable groups with checks or Key Vault.

Choosing quickly

A worked scenario

A GitHub workflow deploys to Azure with a client secret stored as a repository secret. Security wants it removed. The team creates a federated credential on a user-assigned managed identity with a subject for the production environment, gives the identity a narrow role on one resource group, sets id-token: write, and signs in with azure/login using only IDs. The app reads database passwords through Key Vault references, and the old secret is deleted.