There are different ways to add role-based access control to principals for an Azure subscription. These can be done in the IaC with something such as: 

Resource azurerm_role_assignment azure_rbac { 

 scope                                 = var.scope 

 role_definition_name    = var.role_definition_name 

 principal_id                      = var.principal_id 

} 

The scope can be specific to a resource or a resource group or a subscription and takes the fully qualified identifier for the same. 

The role definition name can one of many built-in roles that confers permissions to the principal. For example, this could be Owner, Contributor, Reader, Storage Blob Data Reader and so on. 

The principal_id is typically the object id for the user, group or AD entity. If a service principal is used, it must be the corresponding object id of the paired enterprise application otherwise there will be an error message that states “Principals of type Application cannot validly be used in role assignments”. 

There are many ways to populate the attributes of the resource definition via different IaC definitions, but the provider recognizes them generically as a role assignment. 

The preferences among AD entities for use with deployments is managed identity which can be both system and user defined. The benefit of managed identity is that it can work as a credential as opposed to requiring key-secrets to be issued for an enterprise application. 

Some caveats apply to IaC in general for role assignments. For example, the code that requires to assign an rbac based on the managed identity of another resource might not have it during compile time and only find it when it is created during execution time. The rbac IaC will require a principal _id for which the managed identity of the resource created is required. This might require two passes of the execution – one to generate the rbac principal id and another to generate the role assignment with that principal id.    

The above works for newly created resources with two passes but it is still broken for existing resources that might not have an associated managed identity and the rbac IaC tries to apply a principal id when it is empty. In such cases, no matter how many times the role-assignment is applied, it will fail due to the incorrect principal id. In this case, the workaround is to check for the existence of the principal id before it is applied. 

One of the frequently encountered situations is when the rbac assignments proliferate by iterating over other resource types for their associated managed identities. In such cases, the IaC might only appear as a few lines of code but the compilation and execution might result in a lot more new definitions. When this assignment needs to be changed, usually the same must be applied across all the new role assignments. Even the task of reconciling the state with the actual can become quite tedious and require scripts. There is no default grouping to refer to all these assignments together and action taken on one must be repeated on others. It is advisable to start clean by removing all the assignments from the state and reapplying the new infrastructure role-assignment changes. This guarantees a clean state and baseline before each change.