Local DX for service-to-service authentication based on Managed Identities in Azure

For our internal developer platform, we think about adopting Entra ID for service-to-service auth. This feels natural as all our services are automatically provisioned with a user-assigned managed identity. I believe we will be able to make that work.

The question to those who use it already is how do you deal with local development scenarios?

If a developer wants to locally run service A which needs to authenticate against service B (and normally uses its managed identity in Azure to do that), how to achieve that?

I can imagine some approaches, but I wonder what real-world experience folks have with managing this at scale and not compromise the security posture.

1 Answers

To achieve local development scenarios where a developer wants to locally run a service that needs to authenticate against another service (which normally uses its managed identity in Azure), one approach would be to simulate the service identities locally using a tool such as Azure Identity. This allows developers to authenticate as if they were running in an Azure environment while working on their local machines. This approach can help maintain security posture by ensuring that the authentication mechanisms are consistent with the production environment.