This blog post is the result of a conversation I had last week with a customer, in which we discussed the implementation of Group Managed Service Accounts (gMSA) on Azure Kubernetes Service (AKS) for their application. The result of the conversation was that we found out gMSA was not the best approach for this customer. Instead, pod identity would be a much better option. However, there’s a lot of confusion on what is the difference between these technologies and when to use each. So, let’s clarify things!
Identity for all!
Before we dive into the comparison of the two technologies, it’s important to understand the concept behind them – which is actually the same. Both technologies address the scenario of providing an identity for containerized applications on AKS so workloads running on pods can authenticate securely to access a resource, such as database, a secret on Azure Key Vault, or another Azure service.
Traditionally, AKS would use Service Principals which is comprised of a client ID and a secret or certificate. With that information, the service (AKS in our case) would make an API call to Azure AD to gather an access token. That token could in turn be used to access other Azure resources. However, the maintenance of secrets and certificates can become an overhead. Recently, another approach has taken place: Managed Identities (MI). MIs can be system or user managed and are assigned to the service itself. In the case of AKS, the MI token is assigned to the node pool, so all nodes/VMs on that Virtual Machine Scale Set (VMSS) can use that token to access other services. Applications running on top of a node/VM don’t need to be aware of that mechanism or the token itself. Since this is all managed by the platform, MIs allow for two benefits over Service Principals:
- No need to manage the lifecycle of secrets/certificates.
- No need to provide the credentials to the application, which reduces leaked credentials.
Both pod identity and gMSA take advantage of this mechanism to provide an identity for pods. The problem here is: What is the best one? As any consultant would tell you, it depends.
gMSA versus Pod Identity
The main difference between gMSA and Pod Identity is the scenario they intend to solve. gMSA is intended to support scenarios on which legacy applications that are Active Directory dependent are being containerized. Pod Identity on the other hand, is intended to modern applications that take advantage of Azure AD for authentication. The key difference here is where you host your Active Directory. Let’s look at gMSA first.
gMSA and Active Directory
Imagine you have multiple applications that you are containerizing today, but the Dev team has abandoned the development of these a long time ago. This is a real scenario that customers ask for our help every day. These is traditionally driven by Operations teams or Site Reliability Engineers (SRE) that won’t necessarily change the code of the application. Which means the app has to behave mostly as it was outside of a container. Well, containers can’t be domain joined, but the app still requires Active Directory so it can authenticate either the users that logging into the app, or the app itself so it can access external resources (think of an IIS instance trying to connect to a SQL Database with Windows authentication).
In this case, you have no control over which directory services the app is going to use. It’s all written as part of the application code. Granted you can take some of the app configuration out of the runtime, such as database connection, which domain to use, etc. But the point here is that because you are not changing the application code, you can’t simply switch to Azure AD. gMSA is your only option in this case. It leverages the MI method covered before as part of its implementation on AKS, on which the Windows nodes need access to Azure Key Vault to retrieve a user identity used by the nodes to “talk” to the Domain Controller.
For more information on what gMSA is, how its architecture works, and how to deploy it on AKS, check out our extensive documentation.
Azure AD and Azure AD Domain Services
This is another topic of confusion, specially when evaluating gMSA. The main thing to consider for gMSA is that it needs to talk to a Domain Controller (DC). DCs are available on both traditional Active Directory and Azure AD Domain Services. The main difference is that the latter is offered as a service on Azure.
Azure AD Domain Services should not be confused with regular Azure AD. Azure AD Domain Services is an option to have a managed services for Domain Controllers on Azure, so legacy applications can use that for authentication – think Kerberos.
Azure AD is a managed service for modern authentication on which apps talk directly to its API. gMSA is not available in this mode.
Pod Identity and Azure AD
Pod Identity on the other hand is the opposite of gMSA. It also leverages the MI method discussed above, with the User-assigned MIs. These MIs are bind to pods, so pods can acquire tokens directly. Of course, the implementation of Pod Identity relies on another mechanism to ensure that only allowed pods can acquire tokens of MIs to which they were granted access to, but it allows the application running on that particular pod to access external resources using this methodology. In this case, Azure AD is used for the authentication and both Linux and Windows workloads can benefit from it.
The other thing to know about Pod Identity is that it’s aligned with the latest on authentication with Azure AD. If your Dev team is currently developing the application to be hosted on Azure, Pod Identity should be the option of choice.
Just like gMSA, we have an extended documentation on how Pod Identity works.
Summary
To summarize, take a look at the table below and check which scenario is the one you need:
|
Scenario
|
Pod Identity
|
gMSA
|
|
Directory Service
|
Azure AD
|
Active Directory and Azure AD Domain Services
|
|
OS type
|
Linux and Windows
|
Windows only
|
|
Code changes required
|
App needs to be using a modern authentication method with Azure AD
|
No code changes required
|
I hope this blog post provides a better perspective on what are the scenarios that gMSA and Pod Identity solve. Let us know if you have additional questions on the comments below.
Update: I was reminded on Twitter that Pod Identity will be replaced by Azure AD Workload Identity. Azure AD Pod Identity is currently in Preview, but won't move further as Azure AD Workload Identity takes its place. Azure AD Workload Identity is currently in Private Preview.
