The pipelines of the booking portal of Nordlicht Reisen GmbH, a fictional travel agency, now know six values that must not be public: the connection string of the database, the key of a payment provider, a signing key pair for the mobile app, a key for sending mail, the token of a quality check and the access to Azure. All of them sit in plain text as variables in the pipelines or as a wiki entry. You are to decide for each value whether it has to be a secret at all, where it lives otherwise, and how the pipeline gets it without it appearing in a log.
The exam calls this: using Azure Key Vault in pipelines, using secretless authentication (workload identity federation, OIDC), using secure files and preventing secrets from leaking.
Prior knowledge: How a Key Vault is built, who may access it (RBAC instead of access policies) and how an app loads its secrets from it is shown in K3, lesson 3.3.2. How .NET redacts secrets from logs and how secret scanning and push protection work in GitHub is in K3, lesson 3.3.3; sign-in without a secret in Actions and Azure Pipelines is in K3, lesson 3.7.5 and masking in logs in K3, lesson 3.7.7. Here the focus is the choice and the path in the pipeline itself.
First: does the pipeline need the secret?
In its recommendations on secrets in Azure Pipelines, Microsoft writes: Secrets carry risks of their own, so it is best not to use them at all. The page names three alternatives:
- Service connections for Azure and other services (lesson 5.1).
- Managed identities, with which applications sign in to Azure without an explicit credential.
- The Azure CLI task with
addSpnToEnvironment, to reach details of the service principal without explicitly passing on secrets. According to the task's reference, the option adds the service principal ID, key or federation token, and tenant ID to the script's environment.
So the basic rule is: identity first, then the secret. What is left goes into Key Vault.