skip to Main Content

I’m trying to understand the best practices around maintaining secrets in key vaults:

  • Question 1: Should we give infrastructure access to Azure Key Vault and have the team member access to maintain the secrets?

  • Question 2: Second options is to have a script that would read the values from ADO variable group and then the script would add/update them into the key vault.

I was trying to implement the second option so that we can have all the secrets managed from a single place and this is what happens.

The plan was to have those variables that are supposed to be in KeyVault start with the static string KeyVault_ and then read those using the az pipeline variable group show -- group-id $GROUP_ID but as expected the value is empty for secrets values.

How can I achieve a similar approach and update the key vault secrets from ADO secrets.

$variable_group.variables.GetEnumerator() | ForEach-Object { 
    if ($_.Key.StartsWith("KeyVault_")) {
        $SecretName = $_.Key -replace "KeyVault_", ""
        $SecretValue = $_.Value.value

        if ($SecretValue) {
            Write-Output "Creating secret for $SecretName."
            az keyvault secret set --vault-name $KeyVaultName --name $SecretName --value $SecretValue --output none
            Write-Output "Added secret '$SecretName' to Key Vault '$KeyVaultName'."
        } else {
            Write-Warning "No value found for variable '$($_.Key)'."
        }
    }
}

How can I get the value for $SecretValue assigned properly, I’ve tried $($_.Key) but with no luck!

2

Answers


  1. It’s best to link your Azure DevOps variable groups to Key Vault as detailed in https://learn.microsoft.com/azure/devops/pipelines/library/link-variable-groups-to-key-vaults?view=azure-devops. You should also create separate vaults for different projects because they are relatively cheap – practically free depending on use, which DevOps is unlikely to surpass.

    Yes, you should give trusted members access to update secrets as needed, but it’s best to manage these members assigned to a role using RBAC instead of legacy access policies: https://learn.microsoft.com/azure/key-vault/general/rbac-guide?tabs=azure-cli. This gives them access to update or otherwise rotate secrets.

    It’s really just shifting the problem by giving people access to a DevOps variable group to set these in Key Vault. At some point, a set of individuals has to be trusted to set or even view resources. But Key Vault gives you better protection and auditing than DevOps variable groups.

    Note: if you are using secrets to secure access between services in Azure, it’s actually best you use managed identity whenever possible.

    Login or Signup to reply.
  2. IMO you should use Key Vault to manage the secrets and link the variable groups to secrets in Azure Key Vault.

    A Variable group has limited functionality and scope as compared to Azure Key Vault.

    Azure Key Vault provides centralized secrets management, with full control over access policies and audit history. It supports secrets rotation and versioning to ensure that secrets can be regularly updated without causing disruptions to your automated processes. You can also monitor the vaults/secrets and implement alerting, e.g. when an item is about to expire.

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