Secrets & Secure Pipelines: Key Vault & Workload Federation

Why secrets management is the foundation of secure DevOps

Azure Key Vault

Azure Key Vault is the centralised secret store for Azure environments. It stores three types of objects:

Object Type	Purpose	Example
Secrets	Any string value — passwords, connection strings, API keys	Database password, SaaS API key
Keys	Cryptographic keys for encryption and signing (HSM-backed optional)	Data encryption key, JWT signing key
Certificates	TLS/SSL certificates with automatic renewal	App Service TLS cert, code signing cert

Access control: RBAC vs Access Policies

Key Vault supports two permission models. Azure RBAC is recommended for new vaults.

Key Vault Access: RBAC vs Access Policies

Feature	Azure RBAC (Recommended)	Vault Access Policies (Legacy)
Permission granularity	Per-object-type roles (Secrets Officer, Key Vault Reader, etc.)	Per-vault policy with key/secret/certificate permissions
Scope	Can be applied at management group, subscription, resource group, or vault level	Vault level only
Central management	Yes — same RBAC system as all Azure resources	No — each vault has its own access policy list
Conditional access	Supports Entra ID Conditional Access policies	No conditional access support
Maximum principals	Thousands (Azure RBAC limits)	1,024 access policy entries per vault
Audit	Azure RBAC audit logs + Key Vault diagnostic logs	Key Vault diagnostic logs only

Key Vault RBAC roles

Role	Permissions
Key Vault Administrator	Full management of all vault objects
Key Vault Secrets Officer	All operations on secrets (but not keys or certificates)
Key Vault Secrets User	Read secret values — the role you give to pipelines
Key Vault Certificates Officer	Manage certificates (issue, renew, import)
Key Vault Crypto Officer	All operations on keys
Key Vault Reader	Read vault metadata (not secret values)

Question

What Key Vault RBAC role should a pipeline's service principal have to read secrets at deployment time?

Click or press Enter to reveal answer

Answer

Key Vault Secrets User. This role allows reading secret values but cannot create, update, or delete secrets. It also cannot access keys or certificates unless additional roles are assigned. This follows least privilege — the pipeline only needs to read, not manage.

Click to flip back

Key Vault in pipelines

Azure Pipelines: AzureKeyVault task

The AzureKeyVault@2 task fetches secrets from Key Vault and maps them to pipeline variables:

steps:
  - task: AzureKeyVault@2
    inputs:
      azureSubscription: 'my-service-connection'
      KeyVaultName: 'my-keyvault'
      SecretsFilter: 'db-password,api-key'  # comma-separated, or * for all
      RunAsPreJob: true  # fetch before any other steps

Fetched secrets are automatically masked in logs. They can be referenced as $(db-password) in subsequent steps.

Azure Pipelines: Variable group linked to Key Vault

Instead of fetching per-pipeline, link a variable group to a Key Vault. All secrets from the vault become available as variables in any pipeline that references the group. Changes in Key Vault propagate automatically — no pipeline edits needed.

GitHub Actions: Key Vault with azure/login

steps:
  - uses: azure/login@v2
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  - uses: azure/cli@v2
    with:
      inlineScript: |
        az keyvault secret show --vault-name my-kv --name db-password --query value -o tsv

Alternatively, use azure/cli@v2 with az keyvault secret show to retrieve individual secrets — this is the currently recommended approach.

Question

What are two ways to consume Azure Key Vault secrets in Azure Pipelines?

Click or press Enter to reveal answer

Answer

1. The AzureKeyVault@2 task — fetches specific secrets (or all secrets) from a vault and maps them to pipeline variables in a single pipeline. 2. Variable group linked to Key Vault — link a variable group to a vault, and any pipeline referencing that group gets all its secrets automatically. The variable group approach is better for shared secrets used across many pipelines.

Click to flip back

Workload identity federation in depth

Module 20 introduced OIDC concepts. Here we cover the implementation details.

GitHub Actions OIDC claims

When a GitHub Actions workflow requests an OIDC token, the token contains claims that identify:

• Issuer: https://token.actions.githubusercontent.com
• Subject: Encodes the repo, branch, environment, or tag — e.g., repo:org/repo:ref:refs/heads/main
• Audience: api://AzureADTokenExchange (default for Azure)

The federated credential on the Entra ID app registration specifies which subject claims to trust. This is how you restrict which branches or environments can authenticate.

Subject claim filtering

Filter	Subject Claim	Use Case
Branch	repo:org/repo:ref:refs/heads/main	Only main branch can deploy to production
Environment	repo:org/repo:environment:production	Only the “production” environment can access prod resources
Tag	repo:org/repo:ref:refs/tags/v*	Only tagged releases can publish packages
Pull request	repo:org/repo:pull_request	PR workflows can access read-only resources

Scenario: Amira locks down OIDC for defence pipeline

🏛️ Major Collins requires that only the main branch of the deployment repository can access the production Azure subscription — no feature branches, no PRs, no tags.

Amira’s implementation:

1. Creates an Entra ID app registration defence-prod-deploy
2. Adds a federated credential:
   • Issuer: https://token.actions.githubusercontent.com
   • Subject: repo:defence-org/deploy-infra:ref:refs/heads/main
   • Audience: api://AzureADTokenExchange
3. Assigns the app Contributor role scoped to the production resource group only
4. The GitHub Actions workflow uses azure/login@v2 with the app’s client-id
5. Any attempt to authenticate from a feature branch fails — the subject claim does not match

Result: Even if an attacker compromises a feature branch workflow, they cannot access production Azure resources.

GitHub Actions secrets

GitHub provides three levels of secret storage:

Level	Scope	Set By	Use Case
Repository secrets	Single repo, all environments	Repo admin	Repo-specific API keys
Environment secrets	Single repo, specific environment only	Repo admin	Production credentials (with environment protection rules)
Organisation secrets	Multiple repos (configurable: all, private, or selected)	Org owner	Shared secrets like container registry credentials

Environment secrets are particularly powerful when combined with environment protection rules — require reviewer approval before a workflow job can access the environment’s secrets.

Secret masking in GitHub Actions

GitHub automatically masks any secret value that appears in workflow logs. However, masking has limitations:

• Structured formats (JSON, XML) may partially expose values if the secret appears as a substring
• echo or print statements that transform secrets (base64 encode, substring) may bypass masking
• Multi-line secrets need special handling with add-mask

Azure Pipelines secure files

Secure files store binary files (certificates, provisioning profiles, SSH keys) that pipelines need during execution but should not be stored in source control.

Key characteristics:

• Uploaded to the Azure DevOps project library
• Encrypted at rest
• Downloaded by pipelines using the DownloadSecureFile@1 task
• Pipeline permissions control which pipelines can access each file
• Approval checks can require human approval before download
• Files are placed in a temporary directory and deleted after the pipeline completes

steps:
  - task: DownloadSecureFile@1
    name: sshKey
    inputs:
      secureFile: 'deploy_rsa'

  - script: |
      mkdir -p ~/.ssh
      cp $(sshKey.secureFilePath) ~/.ssh/id_rsa
      chmod 600 ~/.ssh/id_rsa
    displayName: 'Install SSH key'

Question

What are Azure Pipelines secure files, and when should you use them instead of Key Vault secrets?

Click or press Enter to reveal answer

Answer

Secure files store binary files (certificates, SSH keys, provisioning profiles) encrypted in the Azure DevOps project library. Use them for files that must exist on disk during deployment — unlike Key Vault secrets (which are string values), secure files preserve binary format. Pipelines download them with DownloadSecureFile@1, and they are auto-deleted after the job.

Click to flip back

Preventing secret leakage

Pipeline design patterns

1. Never echo secrets — avoid echo $(secret) or print(secret). Even with masking, transformations can leak values.
2. Use secret variables — mark pipeline variables as secret. Azure Pipelines masks them and prevents them from being logged.
3. Audit pipeline outputs — review pipeline logs for accidental exposure. Secrets in error messages are a common leak vector.
4. Restrict fork PR builds — forks can modify workflows to exfiltrate secrets. Require approval for fork PR builds.
5. Separate contexts — production secrets should only be accessible from production deployment stages, not from CI build stages.

Azure DevOps specific controls

• Variable groups with permissions — restrict which pipelines can reference a variable group
• Secret masking — variables marked as secret are masked in all log output
• Audit logs — Azure DevOps audit stream captures who accessed what and when
• Pipeline decorators — inject security scanning steps into all pipelines (org-wide enforcement)

GitHub Actions specific controls

• Required reviewers on environments — secrets in a protected environment cannot be accessed until a reviewer approves
• Deployment branches — restrict which branches can deploy to an environment
• CODEOWNERS — require specific reviewers for workflow file changes (.github/workflows/)
• OpenSSF Scorecards — automated security health check for GitHub repositories

Question

How do you prevent a forked repository from exfiltrating secrets in a GitHub Actions PR workflow?

Click or press Enter to reveal answer

Answer

1. Set 'Require approval for all outside collaborators' on fork PR workflows. 2. Use environment protection rules — fork PRs cannot trigger environment-protected jobs without approval. 3. Set GITHUB_TOKEN to read-only by default. 4. Never pass secrets to steps that run untrusted code. 5. Consider using 'pull_request_target' with caution — it runs in the base repo context and has access to secrets.

Click to flip back

Secret rotation strategy

Secret Type	Rotation Approach	Frequency
Service principal client secrets	Automate with Azure Automation or Logic Apps. Create new secret, update consumers, delete old.	Every 90 days (or eliminate with OIDC)
Key Vault secrets	Enable expiry notifications, automate rotation with Event Grid + Azure Functions	Per compliance policy (30-365 days)
GitHub PATs	Set short expiry, use fine-grained PATs, replace with GitHub Apps where possible	Every 90 days
Certificates	Use Key Vault auto-renewal for supported CAs (DigiCert, GlobalSign)	Before expiry (auto with Key Vault)
SSH keys	Rotate and replace in secure files and Key Vault	Every 6-12 months

💡 Exam tip: Secretless is always the best answer

When the exam presents a scenario asking how to improve pipeline security, the answer hierarchy is:

1. Eliminate the secret entirely — workload identity federation, managed identities
2. Centralise in Key Vault — with RBAC, audit logging, and rotation
3. Use platform secret storage — GitHub Secrets, Azure DevOps secret variables
4. Rotate frequently — short expiry, automated rotation

If an answer option mentions “workload identity federation” or “managed identity” and the scenario supports it, that is almost certainly correct.

Knowledge check

Knowledge Check

Dr. Amira's client stores database passwords as Azure DevOps pipeline variables (not marked as secret). A junior developer's PR accidentally prints the connection string in build logs. What TWO changes should Amira make first?

AMove all secrets to Azure Key Vault with RBAC and link via variable groups. Mark any remaining pipeline variables as secret.BEncrypt the pipeline YAML files and restrict read access to admins only.CDisable pipeline logging entirely to prevent any secret exposure.DCreate a separate Azure DevOps project for pipelines that use secrets.

Check Answer

Knowledge Check

Kai wants his GitHub Actions workflow to deploy to a staging Azure environment from any branch, but only the 'main' branch should be able to deploy to production. He is using workload identity federation. How should he configure this?

ACreate one federated credential with subject filter 'repo:org/repo:*' and use Azure RBAC to restrict production resource accessBCreate two Entra ID app registrations — one with a federated credential for 'ref:refs/heads/*' (staging RBAC) and one for 'ref:refs/heads/main' (production RBAC)CUse a single service principal with a client secret and add a branch check in the workflow YAMLDCreate one app registration with two federated credentials: one for 'environment:staging' and one for 'environment:production', then use GitHub environment protection rules on production

Check Answer

🎬 Video coming soon

Secrets & Secure Pipelines: Key Vault & Workload Federation

Next up: Security Scanning: GHAS, Defender and Dependabot