This is a continuation of previous articles on IaC shortcomings and resolutions. One of the common challenges faced during resource creation are cross-subscription associations. Generally, the subscriptions are independently controlled and IaC deployments are specific to a single subscription at any point of the deployment. However, resources can exist in external subscriptions and become associated with a resource in the current subscription. For example, a private endpoint can be created in the Azure management portal to access an app service in another subscription by specifying the fully qualified resource identifier to the app service and this private endpoint will be created in a local subnet and virtual network in the current subscription.

In such a case, the association must be accepted by the owners of the destination resource. Since the service principal or enterprise application used for the deployment in the current subscription might not have access to the other subscription, the creation of an association resource in the local subscription will fail with the error message that an approval is required, and the instance will not be created. This error message is specific to the automation and not to the manual case when a cross subscription association is created. In the manual case, the resource is created but has a status pending until the owner of the associated resource in the other subscription accepts the connection. The separation of creation and approval stages is only available in the manual case. In the automated case, there is no way to force the creation of the resource and defer the approval process.

The resolution in this case is to grant permissions to the service principal to both create and auto-approve the association with the target resource. The error message will call out the permission required to auto-approve, and this will be part of the permission set of one of the built-in roles. Such a role must be assigned to the service principal used for deployment in the destination subscription/resource group/resource hierarchy. On the Azure portal, the service principal will have permissions menu item against the service principal but admin consent might be required and a service ticket might need to be opened to ask the tenant admin to grant adequate permissions to the service principal. The role assignment is not at the tenant level but at the subscription level and the owners of the targeted subscription can assign the builtin role to this service principal.

It is also possible to have a hybrid approach when creating the resource by doing it manually first, then importing it into the IaC state and finally running the pipeline automation to reconcile the actual resource, the IaC state and the code. Care must be taken to include the attribute necessary to inform the compiler that the resource being created requires a manual connection. Usually, this is done with an attribute like ‘is_manual_connection’ which is set to true.

Finally, it is possible to assign either static or dynamic private ip address to a connection resource without requiring a change to its name. The difference between the two is that we also get an address that does not change just like the name and sometimes the network resolves ip addresses better than names given that DNS registrations might not be added until the resource is created.