GitHub allows you to use secrets in your Actions and manage them directly in the repo using the feature you can find in Settings-->Secrets and variables-->Actions.
But, often, you need to manage your secrets outside the repo (for example because the people who manage the secrets are different from the people who manage the Actions) and, in those scenarios, using Azure Key Vault is a good idea.
Let's imagine we have a Key Vault called GitHubKeyVault
in which we have stored a secret called GitHubSecret
.
Setting credentials and role
Before you can access and use the secret in the Key Vault, you must define a service principal you want to use in the GitHub Action and set the right role (or access policies) in the Key Vault.
To understand how you can create a Service principal for the Action and set the credentials in GitHub, look at my previous post.
Let's suppose that the Service Principal is called GitHubWorkflowDemo
. To set the right permission for the Service Principal in the Key Vault, you can use or RBAC approach or the Key Vault access policies.
We use Access Policies in this post, but using RBAC is very similar.
Open the Key Vault page and select the Access policies blade and click on "+ Create" button:
In the permission step, we need to configure the permissions we want to assign to our Action. Because, it only needs to read secrets, we can select Get
options in Secret permissions
:
In the next step, you need to select the Service Principal created earlier (the Service Principal we use in the Action):
You can skip the next step (Application), because setting the principal you already set an application for the access policy and you can continue creating the policy.
Now you are ready to read and use the secret in the Action.
Using the Azure/get-keyvault-secrets
action
One of the way you can achieve your goal is using the Azure/get-keyvault-secrets
action in your GitHub workflow.
You can write something like this:
name: Secret from KeyVault
on:
workflow_dispatch
env:
SECRETVALUE: ''
jobs:
retrieveWithAction:
runs-on: ubuntu-latest
steps:
- uses: Azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- uses: Azure/get-keyvault-secrets@v1
with:
keyvault: 'GitHubKeyVault'
secrets: 'GitHubSecret'
id: mySecrets
# Starting from here you can use the secret using the
# steps.mySecrets.outputs.GitHubSecret variable
...
The first step of the retrieveWithAction
job of the Action creates a session in Azure using the Service Principal credentials stored in the AZURE_CREDENTIALS
secret.
The second step uses the Azure/get-keyvault-secrets
action to access the Key Vault whose name is contained in the keyvault
parameter to read the secrets listed in the secrets
parameter. The secret will be available in the steps
variables and, in particular, in outputs
collection of the variable whose name is contained in the id
parameter.
You can find more info about this action in its GitHub repo.
Unfortunately this action is no longer maintained (the repository is archived) and is considered deprecated. It works, but it will not be evolved or supported in the future.
Using Azure CLI
Another way you have to read secret from Key Vault is using the az keyvault secret show
command (more info on it here).
You can write something similar to this:
name: Secret from KeyVault
on:
workflow_dispatch
env:
SECRETVALUE: ''
jobs:
retrieveWithCLI:
runs-on: ubuntu-latest
steps:
- uses: Azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Retrieve secret from KV
uses: azure/CLI@v1
with:
inlineScript: |
secretValue=$(az keyvault secret show --name "GitHubSecret" --vault-name "GitHubKeyVault" --query "value")
echo "SECRETVALUE="$secretValue >> $GITHUB_ENV
# Starting from here you can use the secret using the
# SECRETVALUE variable
Similar to the previous approach, you create a session in Azure using the Azure/login
action, but in the second step you use the Azure/CLI
action to retrieve the secret from the Key Vault with the previous CLI command and save it in the SECRETVALUE
variable.
In this approach you need to have a call for each secret and differently from the first approach in which the secrets remain secrets within the action, in this second approach the secrets end up in common variables.
Top comments (1)
Nice