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. As part of the configuration, we also assign the required
API permissions.
As of v4.21.0 of the AzureRM provider, there is now a native
azurerm_function_app_flex_consumption resource for deploying Flex Consumption Function Apps.
Today one of my colleagues asked an excellent question which had me stumped.
He was looking at the Virtual Network Terraform Resource and found the private_endpoint_vnet_policies property,
but couldn’t find any documentation explaining the purpose. So I tried my own Google-fu and similarly failed to find any information.
I did manage to find the privateEndpointVNetPolicies property of the Microsoft.Network/virtualNetworks api,
but as normal the API documentation expects you to understand the settings, it doesn’t explain them to you.
I recently had the privilege of presenting an introduction to GitHub Actions at the New Zealand GitHub User
Group. The recording of the session is available on YouTube.
Coming from Terraform, there are somethings that seem strange in Bicep.
One of those is the way that the Resource Manager API handles assigning User Assigned Managed Identities (UAMIs).
If you look at the API documentation for a resource
(in this case we are going to use an Event Hub Namespace, but this applies to all resources that can have a UAMI assigned)
you will see that the userAssignedIdentities value of the identity property looks lkie this:
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 additional repos to the permission set.