I note that some auth methods, you just create entities and entity aliases, assigning policies typically at the entity (feel free to substitute entity groups for entities in this discussion)
for other auth methods (like aws), you can simply create a backend role, assigning a policy there, and you don’t need to create entities and aliases, they will be autocreated on first login
Is there any documentation or guidance around when it’s advantageous to also precreate entities/aliases along with roles, for those methods?
For context, we configure vault via terraform, not via the gui
I think it largely depends on what your goals are and how flexible you need to be with policy assignment, delegation of administration, and the features you intend to use.
I wrote a small comparison of the different policy assignment methods a while back and intend to update it a bit more based on recent experiences and learning.
Long story short, we were assigning policies directly to roles early on, but have since moved on to extensively leveraging Identity Groups. Only being able to assign policies from one Terraform repo to the role was limiting our ability to delegate access administration. The Terraform Provider for Vault allows you to assign policies to Identity Groups/Entities in a non-exclusive mode (meaning you can have multiple TF states managing membership/policies of a single group), where roles are exclusive only.
Now I’m exploring a take on Microsoft’s AGDLP methodology but leveraging Vault’s Identity Groups. All authentication is performed in a root namespace (the “Global” group equivalent) and secrets reside in child namespaces (“Domain Local” group equivalent). This allows my team to manage the authentication groups centrally while enabling namespace owners to manage what the “authentication” (Global) groups have access to by adding them as members to secret scoped (Domain Local) groups.
In terms of pre-creating entity IDs and aliases, again, it depends on your use case and how you’re using them. For example, if you’re an enterprise customer and want to leverage Control Groups gating manual secret retrieval, having human readable entity names may be beneficial. The entity names (by default, something like entity_1234abcd) will be displayed on the approval workflow. Having a real person’s name may be desirable over a randomly generated user name. However, it may also depend on how many users/objects you’re working with. Terraform may not be best suited for 10s of 1,000s of resources in a single state file, if you have that many to deal with.
In my opinion, I think it would be advantageous to pre-create where you can, if you think you have a need for it and it’s not going to be overly burdensome.
I hope this helps.
Jeff
1 Like
awesome, thanks for writing all that and sharing it here!