skip to Main Content

I’m trying to pre-seed a key-vault with a secret, in an Azure DevOps pipeline.
The key-vault is being generated with ARM in a previous step.

I tried creating a DevOps Service Connection, with "Azure resource manager" as connection type, and I tried both Workload Identity federation and Service principal as authentication method, however, when attempting to add an access policy on the key-vault, the service connection is not listed.

How can I allow my service connection access to my key-vault?

2

Answers


  1. Chosen as BEST ANSWER

    Thanks to the hint of @GalnaGreta, I was able to set the connection up using an RBAC service principal:

    Create the principal:

    az ad sp create-for-rbac -n "sp-keyvault-devops" --role Contributor --scopes /subscriptions/[subscription-id]/resourceGroups/[resource-group-name]
    

    This returns JSON like this:

    {
        "appId": "...",
        "displayName": "sp-keyvault-devops",
        "password": "...",
        "tenant": "..."
    }
    

    Create service connection:

    • Select connection type 'Azure Resource Manager'
    • Select authentication method 'Service principal (manual)'
    • Set 'Subscription Id' & 'Subscription Name'
    • Set 'Principal Id' to the "appId" from above
    • Set 'Tenant ID' to the "tenant" from above
    • Verify and give it a name etc.

    Finally, I could update my key-vault definition to allow get/set/list permissions (bicep):

    {
      tenantId: subscription().tenantId
      objectId: '...' // sp-keyvault-devops
      permissions: {
        secrets: [
          'get'
          'list'
          'set'
        ]
      }
    }
    

    The objectId is not the "appId" from before, but can be found by searching for the service principal in azure.


  2. I have to guess here a bit as you are not showcasing your templates.

    If you are using accessPolicies for granting access to your keyvault secrets, then the accessPolicies array has to be declared in the KV-template, so I am guessing that either you have specified it as accessPolicies: [] (empty array), or having other entries there which does not include the entry you are using for your service-connection object-id.

    So… when you are adding the access-policy for the service-connection in a later step (appending to the array), it would effectively reset/wipe it when the keyvault-template is deployed each time as it is not part of the array defined in the keyvault-template.

    If that is the case, some suggestions for solving it would be the following:

    1. Ensure that the access-policy entry for the service-connection object-id is already part of the KV-template deployment
    2. Switch to using Azure RBAC roles for the access instead (enableRbacAuthorization: true), then once RBAC role-assigment is added on the KV or RG for example, the KV-template deployment would not reset/wipe it as it is handled outside of the KV-template (would also just in general recommend to switch to Azure RBAC for the access).

    If my assumptions were wrong and none of this is actually the issue, then please elaborate!

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search