I'm diving into setting up GitHub Actions workflows for CI/CD at work. We've been using Azure DevOps with Service Principals and client secrets traditionally, but now I'm thinking about shifting to use Azure's OIDC with the azure/login action and Managed Identities (UMI). While researching, I noticed most documentation emphasizes Managed Identities for federated credentials. I found out that UMIs are just an abstraction over Service Principals, which led me to believe that unless I really need client secrets, UMIs are the way to go. However, a new colleague who isn't familiar with UMIs questioned why we shouldn't just stick with Service Principals. After discussing the similarities, he seemed unconvinced, which is why I'm here asking for advice. Is there a solid argument for using Service Principals instead of Managed Identities when both can manage federated credentials? I've read that federated workload identities were designed with Managed Identities in mind, but I still wonder if there are scenarios where Service Principals are superior, especially since creating a UMI solely for GitHub usage seems a bit odd. Most resources suggest using UMIs for internal and Service Principals for external applications, but federated credentials seem to challenge that rule. What do you think?
1 Answer
I feel that if I can use Managed Identities without the hassle of managing secrets, I’m all in for that. Service Principals seem like a fallback option. Just a heads-up, it can be frustrating when some Microsoft services still rely on them, like Fabric for example.
Totally! That was my initial thought too, but I wanted to make sure I could explain my reasoning rather than just saying, "you're wrong" right off the bat! I also appreciate how Managed Identities can be scoped at the subscription and resource group level; makes permissions and clean-up easier.