1

I've created a few integration tests that attempts to access the Azure Key Vault, but fails to do so due to authentication failure. This is triggered by the "Run Tests" task in Azure DevOps.

I've tried including Azure CLI login (for agent) as a preceding step, but seems like each step runs in it's own environment.

Azure DevOps Pipeline Tasks

Here's a snippet of a yaml alternative I unsuccessfully attempted:

steps:
    - task: UseDotNet@2
      displayName: Setup .NET Core
      inputs:
        packageType: 'sdk'
        version: '3.1.x'
    - script: dotnet build --configuration Release
      displayName: Build with dotnet
      workingDirectory: BatchDependencyFnApp

    - script: dotnet test --configuration Release --logger trx
      displayName: Test with dotnet
      workingDirectory: BatchDataRetriever.Tests
      env:
        AZURE_TENANT_ID: $(AZURE_TENANT_ID)
        AZURE_CLIENT_SECRET: $(AZURE_CLIENT_SECRET)
        AZURE_CLIENT_ID: $(AZURE_CLIENT_ID)

The following code is where the auth fails:

    var cred = new ChainedTokenCredential(new ManagedIdentityCredential(), new AzureCliCredential(), new EnvironmentCredential());
    var secretClient = new SecretClient(new Uri(keyVaultUri), cred);
    var opt = new AzureKeyVaultConfigurationOptions { ReloadInterval = TimeSpan.FromHours(24) };
    
    builder.ConfigurationBuilder
        .AddAzureKeyVault(secretClient, opt)
        .Build();

The underlying error message is: Original exception: AADSTS7000215: Invalid client secret is provided.

This works fine locally, as Visual Studio has the login capability. I'm new to all of this, so if somebody could please advise how this could work inside a CI job?

Razeen
  • 252
  • 2
  • 4
  • 14
  • Does this help? https://learn.microsoft.com/en-us/azure/devops/pipelines/release/azure-key-vault?view=azure-devops – Yan Sklyarenko Apr 21 '21 at 08:56
  • You'd need to give the tests credentials through e.g. environment variables, or if using a self-hosted agent, managed identity can be an option as well. Azure CLI credential could in theory work I guess? But it would have to be already authenticated with a service principal etc., which kind of comes back to needing to pass credentials. – juunas Apr 21 '21 at 09:07
  • @YanSklyarenko I've seen that, but that's just a task to get Key Vault secrets as variables for use within other tasks. Has no bearing on the .Net runtime running the tests. – Razeen Apr 21 '21 at 09:21
  • @juunas I've already included the client secret, client id and tenant id as pipeline variables. No difference. – Razeen Apr 21 '21 at 09:21
  • Then you could try adding EnvironmentCredential to that chained credential: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/identity/Azure.Identity/src/EnvironmentCredential.cs. If the variables are available as appropriately named environment variables, it'll use them and get a token. – juunas Apr 21 '21 at 09:28
  • @juunas That unfortunately didn't work. I've tried a new pipeline with yaml, and updated my post with a snippet thereof. – Razeen Apr 21 '21 at 14:18

1 Answers1

0

It could be that you defined AZURE_CLIENT_SECRET as a secret in your Azure Devops pipeline variables. These values cannot be picked up outside regular build steps. Neatly explained in this answer: https://stackoverflow.com/a/50113557/2915851

The solution is to export the secret variable in a cmd/powershell script before you use it in subsequent steps:

Write-Host "##vso[task.setvariable variable=AZURE_CLIENT_SECRET;]$(AZURE_CLIENT_SECRET_VALUE)"

Note: key here is to have a different name for the variable in your pipeline variables list. If the variable name is identical to the environment variable you want to reveal to subsequent tasks, Azure Devops makes it secret (again).

The other variables (AZURE_TENANT_ID and AZURE_CLIENT_ID) can remain as regular pipeline variables and do not need to be exported for the UseDotNet@2 task to access them.

veuncent
  • 1,599
  • 1
  • 20
  • 17