If you're using AAD for authentication in other parts of your organization, there's a good chance you should be using it for Vault, too.
LDAP, compared to OIDC, is insecure. And don't even get me started about the potential problems at scale with good ol' userpass...
To do this, you'll need to make an App Registration for Vault Enterprise.
Then, you'll need to follow these instructions, but figure out how they work with Azure Active Directory instead of Auth0:
https://learn.hashicorp.com/tutorials/vault/oidc-auth?in=vault/auth-methods
(Guess which one is easier...)
But you have a few choices about what to do with that App Registration you make in Azure Active Directory.
Approach number 1: Use AAD's idea of App Roles.
AAD has an idea of "App Roles" in its App Registration manifests. These App Roles can be assigned to various groups, and provided as a "claim" in part of the JWT (JSON Web Token) in OIDC. Every time you want to add a new Azure AD "App Role," though, you have to edit the "Manifest" of the App Registration to add items to the JSON array labeled 'appRoles'. If you need to have an AAD Security Group with a different Vault Policy or set of Policies, you'll need add yet another Azure AD App Role, and a new Vault Auth Role in the Vault OIDC Auth Method for your Azure AD App Registration. Then, you add the AAD Security Group to your App Registration, and assign it the new AAD App Role you just made in your AAD App Registration.
Approach number 2: Use Vault Identity Groups
Skip the AAD App Roles, which have a limit of 1200 roles, and AAD App Roles require painful mutation of the "Manifest" by hand. Just use Vault Identity Groups instead. To each Vault Identity Group, you add an Identity Group Alias, and name that Identity Group Alias after the "Object Id" of the AAD Security Group that you want in Vault Enterprise. This means you still get to have AAD as an identification store and "source of truth" for authorization, where removal from or addition to AAD Security Groups controls authentication & authorization in Vault. But you also don't have to edit any JSON manifests.
Approach number 3: Use Vault Entities
A third approach, for admins of Vault Enterprise, would be to map various AAD user aliases to corresponding "entities" in Vault Enterprise's "Identity" Secrets Engine, then add those "entities" to the Vault Identity Groups that have various policies associated to them. I guess it is more of an onboarding scenario in which Vault manages much of the identification, and, because this is all done on a user-by-user basis, this entails no mapping of any given AAD Security Groups to Vault Identity Groups. It's a bit tricky, since Vault, at this point, is its own "source of truth" for permissions, and the only thing AAD is getting used for is to determine whether they have a valid AAD User.
Top comments (0)