2 minute read
You can and maybe should use a separate and centralized location to store your secrets as opposed to using GitHub Secrets itself. By using a centralized location you can better control where your (probably multiple) secrets are and thus be sure that you are in control. If you store the secrets in GitHub they are still secure but maybe harder to keep control of. You may have secrets in multiple GitHub repository or organizations. It could quickly become a bit chaotic.
This page will step through a configration that uses an Azure key vault to store the secrets of an service principle with contributor rights.
get
and list
permissions agains the Azure Key vault but this command just creates the SPN with no roles or rights yetaz ad sp create-for-rbac --name "spn-reader-example"
Create an Azure service principal name (SPN) with a client secret
AZURE_CREDENTIALS
{
"appId": "00000000-00000-0000-0000-000000000000",
"displayName": "spn-reader-examle",
"password": "0000000000000000000000000000000000000000",
"tenant": "00000000-0000-0000-0000-000000000000"
}
get
and list
rights for the SPN created in the previous step to the key vault access policyappID
is the value generated as the output from the SPN create stepaz keyvault set-policy -n {keyVaultName} --secret-permissions get list --spn {appID}
az ad sp create-for-rbac --name "spn-contributor-example" --role="Contributor" --scopes="/subscriptions/00000000-0000-0000-0000-000000000000"
Create an Azure service principal name (SPN) with a client secret
Use Key Vault secrets in GitHub Actions workflows
Was this page helpful?
Glad to hear it!
Sorry to hear that.
This is a production site.