Frequently asked by our clients Through the use of Terraforms or biceps, my IAM team surrendered control over service principals/Workload identities that were developed by developers utilizing IaC code.?
Workload Identities serve as mechanisms for distinguishing non-human entities that exist within a Microsoft Environment. This may include permissions required by a web application as well as more permissive constructs utilized in the automated deployment of infrastructure. They constitute a robust framework that is implemented in virtually every Azure cloud architecture.
As a best practice they are usually kept outside MFA but there are few risks outlined below that needs to be mitigated
- They are often used to execute extremely permissive operations, including Terraform/IAC deployment pipelines.
- Failure to utilize a managed identity necessitates the storage of client secrets in an unsecure location, which may expose one to vulnerabilities such as keys being appended to source code.
- They are unable to employ multi-factor authentication.
- Frequently, lifecycle management (specifically identifying and removing unused identities) requires a cost.
- It may be more difficult to identify and monitor audit logs since they are not necessarily associated with a specific individual or team.
Workload Conditional Access just went to GA in November 2023, while Entra Conditional Access has been offered to users for a long time. It makes it so that the Workload Identities can only get an access code when certain conditions are met. This adds an extra robust layer of security.
Presently, two primary use cases are readily available:
You can use location-based conditional access, which is a strong defense-in-depth method, to make sure that workload identities can only be used from IP ranges that you own or control. You can now make sure that Service Principal is only used from known places if you are running a permissive Terraform Deployment pipeline from a Self Hosted Github Agent. Any attempt to log in with the client ID and secret from a place that isn’t allowed would be stopped.
Risk-based conditional access—Microsoft’s smart identity protection barriers can detect Service Principal or Identity misuse. Access from known suspicious IP addresses, unusual utilization patterns, or a known credential leak are all examples of such vulnerabilities. Every sign-in is assigned a risk assessment by Microsoft, ranging from Low to High. Thereafter, service principal usage exceeding a specified risk rating can be blocked.
In summary an interesting aspect at last, it enables you to implement a comprehensive defense for your Workload Identities. Implementing this approach mitigates several limitations and prevalent vulnerabilities associated with the utilization of identities not based on user or burden.
Microsoft reference Microsoft Entra Conditional Access for workload identities – Microsoft Entra ID | Microsoft Learn
