davidelettieri / bicep-github-actions

A reference implementation of using GitHub Actions to deploy infrastructure to Azure using Bicep

GitHub Actions Workflows for Bicep

This is a sample repository that shows how to use GitHub Actions workflows to manage Azure infrastructure with Bicep.

Architecture

Dataflow

1. Create a new branch and check in the needed Bicep code modifications.
2. Create a Pull Request (PR) in GitHub once you're ready to merge your changes into your environment.
3. A GitHub Actions workflow will trigger to ensure your code is well formatted, internally consistent, and produces secure infrastructure. In addition, a What-If analysis should run to generate a preview of the changes that will happen in your Azure environment.
4. Once appropriately reviewed, the PR can be merged into your main branch.
5. Another GitHub Actions workflow will trigger from the main branch and execute the changes using Bicep.

Workflows

1. Bicep Unit Tests This workflow runs on every commit and is composed of a set of unit tests on the infrastructure code. It runs bicep build to compile the bicep to an ARM template. This ensures there are no formatting errors. Next it performs a validate to ensure the template is deployable. Lastly, checkov, an open source static code analysis tool for IaC, will run to detect security and compliance issues. If the repository is utilizing GitHub Advanced Security (GHAS), the results will be uploaded to GitHub.

2. Bicep What-If / Deploy This workflow runs on every pull request and on each commit to the main branch. The what-if stage of the workflow is used to understand the impact of the IaC changes on the Azure environment by running what-if. This report is then attached to the PR for easy review. The deploy stage runs after the what-if analysis when the workflow is triggered by a push to the main branch. This stage will deploy the template to Azure after a manual review has signed off.

Getting Started

To use these workflows in your environment several prerequisite steps are required:

1. Create GitHub Environments The workflows utilizes GitHub Environments and Secrets to store the Azure identity information and setup an approval process for deployments. Create an environment named production by following these instructions. On the production environment setup a protection rule and add any required approvers you want that need to sign off on production deployments. You can also limit the environment to your main branch. Detailed instructions can be found here.

2. Setup Azure Identity: An Azure Active Directory application is required that has permissions to deploy within your Azure subscription. Create a single application and give it the appropriate read/write permissions in your Azure subscription. Next setup the federated credentials to allow the GitHub to utilize the identity using OIDC. See the Azure documentation for detailed instructions. Three federated credentials will need to be added:

   • Set Entity Type to Environment and use the production environment name.
   • Set Entity Type to Pull Request.
   • Set Entity Type to Branch and use the main branch name.

3. Add GitHub Secrets Note: While none of the data about the Azure identities contain any secrets or credentials we still utilize GitHub Secrets as a convenient means to parameterize the identity information per environment.

   Create the following secrets on the repository using the Azure identity:

   • AZURE_CLIENT_ID : The application (client) ID of the app registration in Azure
   • AZURE_TENANT_ID : The tenant ID of Azure Active Directory where the app registration is defined.
   • AZURE_SUBSCRIPTION_ID : The subscription ID where the app registration is defined.

   Instructions to add the secrets to the repository can be found here.

Additional Resources

A companion article detailing how to use GitHub Actions to deploy to Azure using IaC can be found at the DevOps Resource Center. TODO: add link