1

I have 2 Azure resources in an ARM template that depend on each other: a key vault and a service fabric cluster.

For the key vault, I need to reference the service fabric cluster's object ID in the key vault's access policies to give it permission to access secrets. For the service fabric cluster, I need it to reference secrets from the key vault. Neither of these resources exist during deployment time.

Is there a way that I can reference the object ID of the service fabric cluster to provide to the key vault's access policies, and is there a way that I can generate the secrets in the key vault without hardcoding any values? Ideally, we would only know the secret name and only provide that secret name to the service fabric cluster in the ARM template.

Improve this question
7
  • but you dont need certificates for the servicefabric resource, only their dns names Commented Apr 24, 2020 at 4:24
  • @4c74356b41 sorry I should have been more specific. In this case it's not certificates but secrets. One of the URLs to the secrets is specified in a configuration file that the service fabric app resource will read from, and the other is a secret specified for the service fabric cluster username and password for login in the ARM template. Commented Apr 24, 2020 at 16:14
  • I dont see a chicken and egg problem anywhere here. To pull data from keyvault at deployment you need to grant access to the template (or vmss) to the key vault, that is done from the advanced access policies and that can be done at anytime. even if there is something that needs to be pulled from the servicefabric resource itself - you can do that when its ready, but before creating scale sets Commented Apr 24, 2020 at 16:16
  • On first deployment, neither resource will exist. We need to be able to deploy the key vault with the secrets, as well as specify the service fabric apps object ID in the key vault's access policy. The problem is, there is no way to specify the service fabric app's object ID during first-time deployment, as the resouce doesn't exist. The other issue, if we delpoy the service fabric app first just to get the object ID, the service fabric app will run and fail to get the secret because it doesn't have access yet. Commented Apr 24, 2020 at 19:59
  • I assume you're using an MSI? Not sure if SF will let you do this, but you need to separate and update the deployments. Deploy SF w/o secret in an "offline" state, create the vault, then redeploy SF to the final state... Commented Apr 24, 2020 at 23:33

2 Answers 2

Reset to default
1

I believe I have a similar situation where I have a Key Vault that contains secrets and certificates that are referenced by a Service Fabric Cluster (SFC), and then I need to grant permission for a SFC Managed Identity to have access back to the Key Vault. I use a combination of PowerShell and nested/linked ARM templates.

Launch single PowerShell script by Azure DevOps pipeline that handles deployment steps below:

  1. Deploy Key Vault by ARM
  2. Import secrets and certificates into KV by PS
  3. Deploy SFC by ARM (references KV secrets)
    1. After SFC (by dependson), perform ARM deployment to set KV access policy

Example from Microsoft: https://github.com/Azure/azure-quickstart-templates/blob/master/101-keyvault-add-access-policy/azuredeploy.json#L35

 { "type": "Microsoft.KeyVault/vaults/accessPolicies", "name": "[concat(parameters('keyVaultName'), '/add')]", "apiVersion": "2019-09-01", "properties": { "accessPolicies": [ { "tenantId": "[parameters('tenantId')]", "objectId": "[parameters('objectId')]", "permissions": { "secrets": "[parameters('secretsPermissions')]" } } ] } }

Everything is deployed and setup with a single release.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Super underrated but so helpful. Which I would have seen this about 4 hours earlier today :)
0

Key Vault Access Policies are 1st class ARM Resources. They don't have to be created as a child of a Key Vault resource.

As a resolution to the problem you encountered, this is what I did:

  1. Created a "Main" bicep template"
  2. Created a bicep module for a function app - output functionApp.identity.principalId
  3. Created a bicep module for a key vault
  4. Created a bicep module for key vault access policies that receives principalid from point 2 as a param and grants permission for the key vault

enter image description here

Improve this answer

Comments