Technology for the Glory of God
One challenge we often run into when provisioning Azure AD applications with Terraform is a need to grant admin consent for API permissions. Sadly there is not a native resource within Terraform to make this happen, however with some creative use of provisioners (yes, I feel bad about it too) we can ensure that admin consent is granted for our applications. To start with, we deploy our Azure AD application as normal.
In a recent project we used GitHub Actions to deploy our Terraform code. While not the best way to deploy Terraform, we had it working nicely. One of the biggest challenges we encountered was how to download the private Terraform modules we had created. In a GitHub Actions workflow you can specify the permissions that the runner should be granted. However, these permissions are scoped to the repository that the Action is running on, and it is not possible to add additonal repos to the permission set.
In my current role, I configured Terraform to manage our GitHub organisation. As with all providers, we need need to provide credentials for authentication. I didn’t want to use an access token, as they are tied to an individual user and will cause breakage should the user depart the organisation. Thankfully, GitHub supports using an application for authentication. Create the GitHub Application The first step in the process is to create a new GitHub application.
Managed Identities in Azure are a wonderful thing. No passwords to change, no keys to rotate. The biggest shame is that frequently they seem to be implemented as an afterthought. One example I recently ran into was the use of an App Service Managed Identity to pull a container from Azure Container Registry. While you can configure an App Service to pull from ACR with a Managed Identity, what the documentation doesn’t tell you is that you still need the DOCKER_REGISTRY_SERVER_USERNAME and DOCKER_REGISTRY_SERVER_PASSWORD App Settings to be configured on the App Service.
Terraform is a fantastic tool for Infrastructure as Code. From the YAML-like HCL syntax (no JSON!), to importing files (linting JSON files FTW!), to retrieving the results of previous runs to link resources, Terraform has made a massive difference in my work. However, like all technologies, it is not without its weaknesses. Terraform uses state files to keep track of what the world looked like when it last ran, which is wonderful for identifying drift.
Not everyone is privileged to be able to use Terraform Cloud for deploying their Terraform infrastructure. This means that teams need to use their existing DevOps tooling to deploy their infrastructure via Terraform. While I’ve seen many examples of pipelines for deploying Terraform code with various services, it felt like something was missing. Most example pipelines were designed to just run once a code review had occurred, and often would automatically deploy the changed code without any intervention.
Traffic Manager is an essential component of any resilient deployment within Azure. Whether you have a multi-region behemoth, or simply want a simple way to activate DR instances should the primary go down, Traffic Manager has a configuration for you. One key component of Traffic Manager is its probes—by frequently checking the status of your application, Traffic Manager can make intelligent decisions about where to direct the traffic. As with all services, there are a specific set of IP addresses from which the probes will originate.