The safest pipeline secret is the secret the pipeline no longer needs to store. Azure DevOps can use workload identity federation for many Azure service connections, replacing long-lived client secrets with short-lived token exchange. When static sensitive values are still required, Azure Key Vault, secret variables, variable groups, and secure files provide controlled storage patterns. The current AZ-400<\/a> objectives explicitly include Key Vault, secretless authentication, workload identity federation, secure files, service connections, and preventing sensitive information from leaking through automation.<\/p>\n Secret management therefore starts before the question \u201cWhere do we save the password?\u201d Teams should identify which credentials can be eliminated, which must remain, who can use them, how they are rotated, how logs are protected, and how compromise is detected and contained. A pipeline can mask a value on screen and still be overprivileged or operationally unsafe.<\/p>\n Not every sensitive item behaves the same way. API keys, passwords, client secrets, private keys, certificates, signing material, license files, and connection strings have different formats and rotation patterns. Some are simple secret values. Others are files or cryptographic objects that need controlled handling.<\/p>\n Map each credential to the system it grants access to and the minimum operations the pipeline needs. A deployment credential for one resource group should not be reused for package publication, database administration, and unrelated production subscriptions. Shared credentials increase the blast radius and make rotation more disruptive.<\/p>\n Where the target supports federation or managed identity, prioritize removing the stored credential. Secret storage is valuable, but elimination is stronger because there is nothing long-lived to steal or forget to rotate.<\/p>\n Build a credential inventory that records purpose, owner, target system, environment, privilege, storage location, rotation method, and consumers. This turns secret handling from tribal knowledge into an operable system. It also reveals duplication: the same credential may have been copied into multiple variable groups, scripts, and agents even though only one service connection is required. Removing unnecessary copies reduces both attack surface and rotation effort.<\/p>\n Avoid labeling ordinary configuration as secret simply because it is sensitive to change. Over-classification makes pipelines harder to debug and encourages teams to place nonsecret operational values in restricted stores. Separate confidentiality from integrity: some values need controlled modification but do not need to be hidden from logs or reviewers.<\/p>\n Azure Resource Manager service connections can use workload identity federation so Azure Pipelines authenticates without storing a client secret. Microsoft recommends workload identity federation for supported Azure Resource Manager connections. New eligible connections use the Microsoft Entra issuer, and older connections that use the deprecated Azure DevOps issuer should be converted before that issuer retires.<\/p>\n Federation changes credential lifecycle but not authorization. The associated app registration or managed identity still needs Azure role assignments. Grant the smallest practical scope and avoid giving one service connection broad permissions across development, staging, and production.<\/p>\n AZ-104<\/a> knowledge is useful because service-connection security depends on Microsoft Entra identities, RBAC scope, managed identities, subscription structure, resource groups, and networking decisions outside Azure DevOps itself.<\/p>\n Federation should be the default for new Azure service connections when the target scenario supports it. Current Azure DevOps guidance uses Microsoft Entra as the issuer for new workload identity connections; older Azure DevOps-issued connections are on a deprecation path and should be planned for conversion. Migration should verify both authentication and the Azure role scope so replacing the credential does not silently preserve excessive privilege.<\/p>\n When a pipeline needs a real secret, Azure Key Vault provides a managed system for secrets, keys, and certificates. Azure Pipelines variable groups can link to an existing Key Vault and map selected secrets. The pipeline retrieves current secret values at runtime instead of storing copies directly in the pipeline definition.<\/p>\n Key Vault integration does not remove the need for permissions. The service connection used by the pipeline must be authorized to retrieve the required secrets, and vault networking must allow the job to reach the service. Private endpoints or firewall restrictions can change where pipeline agents need to run and how DNS resolves the vault.<\/p>\n The operational lessons from Azure Key Vault lifecycle management<\/a> apply here: ownership, versioning, rotation, access, and expiry should be designed together rather than treating the vault as a permanent bucket for values.<\/p>\n Design the mapping between Key Vault and pipeline libraries deliberately. A variable group linked to a vault retrieves values for mapped secret names at runtime, but adding or removing secret names in the vault does not automatically redesign the variable group. Treat that mapping as configuration with review and ownership. Otherwise teams can believe a newly rotated or renamed credential is available to a pipeline when the pipeline is still bound to an older name.<\/p>\n Network design can affect secret retrieval. A locked-down vault may require private endpoints, approved networks, or an agent with the correct route and DNS resolution. Test this path from the actual execution environment rather than from an administrator workstation. Many \u201csecret\u201d failures are really identity or network-boundary failures, and broadening vault access during an outage can create a permanent security exception if the underlying cause is not understood.<\/p>\n Azure Pipelines can mark variables as secret and masks recognized secret values in logs. Secret variables are not automatically exported as environment variables; scripts should map only the values they need. This reduces accidental exposure through inherited process environments.<\/p>\n Do not store secrets directly in YAML. Command lines can also leak values because operating systems and tools may log arguments. Prefer environment mapping, supported task inputs, or files with controlled permissions when a tool requires sensitive data.<\/p>\n Masking is a defense-in-depth feature, not permission to print secrets. Avoid structured secrets that contain common substrings because masking may not cover every fragment in every context. Debug logging should be carefully controlled around authentication and deployment steps.<\/p>\n Limit secret lifetime inside the job. Map a value only to the step that consumes it, avoid writing it to shared workspace files, and clear temporary material when tools do not do so automatically. Debug modes deserve special caution because verbose output can reveal headers, command substitutions, or configuration files that normal logs omit. Troubleshooting should never start by printing the entire environment.<\/p>\n Some deployments require certificates, provisioning profiles, keystores, configuration bundles, or other sensitive files. Azure Pipelines secure files can store protected files separately from the repository and make them available to authorized pipelines during a job.<\/p>\n Limit which pipelines and users can access the file, download it only for the step that needs it, and delete temporary copies when the tool does not handle cleanup automatically. A secure file that is copied into a published artifact or cached on a persistent agent is no longer secure merely because its original storage was protected.<\/p>\n Where possible, move toward systems that perform signing or cryptographic operations without exporting private key material to the build host. The less sensitive material that reaches an agent filesystem, the smaller the exposure surface.<\/p>\n Secure files should have the same ownership discipline as secrets. Record why the artifact exists, which pipelines can use it, when it expires, and how it is replaced. Certificates and signing assets often fail operationally because teams discover expiry only during a release. Monitoring and rehearsal are as important as protected storage, especially when renewal requires an external issuer or coordinated application update.<\/p>\n Pipeline libraries can make reuse convenient, but broad authorization can quietly increase risk. Avoid granting every pipeline access to every variable group or service connection. Authorize only the repositories and pipelines that need the resource, and review those grants as applications are retired or responsibilities change.<\/p>\n Separate environments. Development workflows should not receive production Key Vault secrets. Production service connections should not be callable from arbitrary feature branches. Protected environments, approvals and checks, branch controls, and service-connection permissions should reinforce each other.<\/p>\n The same least-privilege principle appears in infrastructure automation security<\/a>. The tooling may differ, but credentials should be narrowly scoped, short-lived where possible, and separated by trust boundary.<\/p>\n Prefer explicit pipeline authorization to global convenience. A shared library can still be organized for reuse, but production credentials should be exposed only to approved pipelines and branches. Review inherited permissions when projects, groups, or service connections change ownership. Access that was reasonable for a small team can become overbroad after organizational growth if the authorization model is never revisited.<\/p>\n A secret with no owner or expiry becomes permanent infrastructure. Record who owns each credential, where it is used, when it rotates, and what will break if the rotation fails. Automated rotation is valuable, but it must update consumers or rely on runtime retrieval so a new version becomes usable without manual copying.<\/p>\n Key Vault-linked variable groups automatically receive updated values for secrets that are already mapped, but adding or removing secret names requires the variable group mapping to be updated. That detail matters when teams assume the integration automatically mirrors every vault change.<\/p>\n Test rotation before an emergency. Change a nonproduction credential and prove that pipelines continue to work. The first rotation exercise often reveals hidden copies in scripts, wiki pages, local agent configuration, or external systems that were not part of the documented design.<\/p>\n Automate rotation where the dependent system supports it, but keep a tested manual recovery path. Automation can fail because of policy, network, identity, or naming changes, and an emergency rotation is the worst time to discover that nobody knows how the consumer is configured. Track upcoming expirations and rotate before the final window so failures can be corrected without creating release pressure.<\/p>\n Choose rotation frequency from the credential\u2019s risk and the target system\u2019s capabilities rather than one universal calendar rule. High-privilege reusable credentials deserve shorter lifetimes than low-impact values, while federated identities may eliminate scheduled secret rotation entirely. Whatever interval is selected, the process should be observable so missed rotations, failed updates, and orphaned consumers are detected before expiry becomes an outage.<\/p>\n Self-hosted agents are useful for private networking and specialized tooling, but they can retain state between jobs. Secrets can leak through temporary files, tool caches, process environments, shell history, diagnostic logs, or improperly cleaned workspaces. Treat the agent as part of the secret boundary.<\/p>\n Use ephemeral agents where practical for high-trust workloads. If persistent agents are required, isolate pools by trust level, patch them, restrict interactive access, clean workspaces, and limit outbound network destinations. Do not run untrusted pull-request code on the same persistent host that receives production credentials.<\/p>\nClassify sensitive information before choosing storage<\/h3>\n
Use workload identity federation for Azure access<\/h3>\n
Use Azure Key Vault for managed secret values<\/h3>\n
Handle secret variables as temporary runtime data<\/h3>\n
Use secure files for sensitive deployment artifacts<\/h3>\n
Scope service connections and variable groups deliberately<\/h3>\n
Design rotation and expiry before credentials are issued<\/h3>\n
Protect self-hosted agents from secret residue<\/h3>\n