How do you safely manage Entra ID role assignments and Privileged Identity Management (PIM) eligibility with Terraform? The deployment service principal needs a highly privileged role to assign directory roles or create PIM-eligible assignments, which means it could potentially grant Global Administrator. If the pipeline or its credentials were compromised, the blast radius would be substantial. Is this risk generally accepted, or are there controls that prevent the service principal from granting highly privileged roles? Can the service principal's privileged role be activated only for the duration of a pipeline run, perhaps through PIM, instead of being permanently assigned?
2 Answers
There does not seem to be a fully clean solution. One option is to activate Privileged Role Administrator through PIM as a human operator, then run the Terraform that manages role configuration using your own identity outside the pipeline. That reduces the standing privilege but sacrifices full automation. If the work must run in a pipeline, the service principal generally needs Privileged Role Administrator assigned before the run. You could isolate that assignment in a small Terraform root module, apply it immediately before the main deployment, and destroy it afterward. Even then, the service principal is temporarily highly privileged, so access to the pipeline and the specific service principal must be tightly controlled.
Service principals cannot activate PIM roles interactively during a pipeline run in the same way users can. The usual mitigation is to keep the pipeline identity tightly scoped operationally: restrict who can start or modify the relevant pipelines, limit which pipelines are allowed to use that service principal, protect pipeline configuration and credentials, and separate ordinary deployments from privileged role-management workflows. This does not eliminate the underlying privilege requirement, but it reduces the chance that an unrelated pipeline or compromised build process can abuse it.
Have you seen this kind of role management as code used in production? I’m wondering whether organizations generally accept the temporary or standing privilege, or avoid automating these changes altogether.
Has anyone implemented Entra ID role management as code successfully in a production environment? There seems to be very little practical guidance, so I’m trying to work out whether this approach is considered viable.