OpenID support for GitHub in Azure Active Directory was announced this year, opening up several security advancements. As part of this post, an Azure Back to School 2022 special, we go into how to configure OpenID Connect, enabling us to drop the use of client secrets when authenticating.
Prerequisites
I recommend reviewing the following security hardening and configuration document Microsoft has published to educate adopters:
Hardening with OpenID Connect
You will need the following to be able to complete actions:
- Azure Active Directory permissions to create a new AzureAD application
- Permissions to add a role to an Azure AD app within a Subscription
- A GitHub organisation
- GitHub permissions to add secrets to a repository
Why use Open ID than Client Secret
OpenID allows for better security by providing granular control by authorising access based on where authentication is coming from. For example, we can explicitly say that the AzureAD app is federated with GitHub, so authentication requests must go through here. We can then set it so only a specific repository can be authorised and based on the following:
- Environment
- Branch
- Pull Request
- Tag
Where client secrets can be used and shared by multiple sources with no control or visibility, OpenID adds this necessary control and additional layers to control what is accessing your Azure subscriptions fully.
Creating the Azure Active Directory Application
To start, we need to create the AzureAD application by following the below steps:
- Open Azure Active Directory and select App registrations and New registration
- Enter an appropriate name and select Single tenant. When ready, select Register.
Now we need to create a federated credential. For this, I will configure the credential to a repository, which can only be used when a GitHub Action runs on a specific branch. Follow the below steps, and replace the values to fit your setup:
- Within the newly created AzureAD application, select Certificates & secrets, then the Federated credentials tab and select Add credential
- From the Federated credential scenario drop-down, select GitHub Actions deploying Azure resources
- Now you need to configure the following:
- Organisation: The name of the GitHub Org where the repository is located
- Repository: The name of the repository you are authorising access
- Entity type: The type of entity (environment, branch, pull request, tag) that will be authorised when the GitHub Action runs
- GitHub branch name: Because I'm using a branch as the entity, I am provided with this option where I enter the name of the branch which is authorised to access the Azure subscription
- Name: The display name for the credential within the AzureAD application
When ready, select Create
Assign a Role in your Subscription
Now with the configurations within Azure Active Directory completed, we need to assign the application a role within an Azure subscription. Search IAM for the AzureAD app you created and assign it a role.
Add Secrets to GitHub
In the GitHub repository, you need to add the following secrets:
AZURE_CLIENT_ID - The Client ID is available on the overview page of your AzureAD application.
AZURE_TENANT_ID - The Tenant ID used to authorise the login. This is also available on the overview page of your AzureAD application.
AZURE_SUBSCRIPTION_ID - This would be the Subscription ID where you assigned a role to the Azure Active Directory application. Authentication will fail if you attempt to use a subscription where you didn't assign a role to the AzureAD application.
As you can see, there is no need for a client secret due to the trust relationship between AzureAD and GitHub, which generates a token during a GitHub Action run.
Within the GitHub Action you are configuring, you must log in to Azure with the new credential. We need to add permissions and then the Azure CLI login action, which will authenticate using the secrets we stored in GitHub.
name: Deploy Azure App
on:
push:
branches:
- main
permissions:
id-token: write
contents: read
jobs:
Deploy:
runs-on: ubuntu-latest
steps:
- name: Azure CLI Login
uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
How we could manage this as code
Moving forward, you may want to manage this using an "as Code" method whereby creating and deleting are done using a pull request and automated deployment. This can probably be achieved using Terraform, but I have yet to test this.
In theory, you can probably use the AzureAD provider and the following resource - Application Federated Identity Credential - to create the federated credentials in an Azure Active Directory Application.
It will look something like this:
resource "azuread_application" "github_oidc_manage" {
display_name = "GitHub OIDC Management"
}
resource "azuread_application_federated_identity_credential" "github_oidc_org-repo_env" {
application_object_id = azuread_application.github_oidc_manage.object_id
display_name = "org-repo-env"
description = "Deployments for org-repo-env"
audiences = ["api://AzureADTokenExchange"]
issuer = "https://token.actions.githubusercontent.com"
subject = "repo:My-Org/org-repo:environment:prod"
}
Thank you for reaching the end of the post. Please make sure you check out the rest of the content being released as part of the Azure Back to School event.
