Vault’s identity system is the secret sauce that lets you manage who is allowed to do what, without scattering credentials everywhere. It’s not about users and passwords in the traditional sense; it’s about abstracting identity so that any system, service, or human can authenticate to Vault and get a temporary, role-based credential.
Let’s see it in action. Imagine you have a web application that needs to talk to a database. Instead of embedding database credentials in the app, the app will authenticate to Vault.
# First, the app gets a token from Vault using its own identity mechanism (e.g., a Kubernetes service account token, AWS IAM role, or even a username/password).
# For demonstration, let's say it uses a Kubernetes service account.
vault write auth/kubernetes/login \
role=my-web-app-role \
jwt=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
# This returns a Vault token. Now, the app uses this token to request a database credential.
vault read database/creds/my-db-role
This request doesn’t just magically work. Vault has a concept of Entities, Aliases, and Groups that make this possible.
An Entity is the core representation of a subject that can authenticate to Vault. Think of it as the fundamental "thing" that has an identity. This "thing" could be a human operator, a specific server, a Kubernetes pod, an AWS EC2 instance, or any other identity source. Entities are unique within Vault and persist. They are the backbone upon which all other identity information is built.
Aliases are the bridge between an external identity system and a Vault Entity. When a specific identity source (like Kubernetes, AWS, or even LDAP) authenticates, it creates or links to an Entity. An Alias is essentially a pointer from an external identity (e.g., a specific Kubernetes service account token, an AWS IAM ARN) to a Vault Entity. A single Entity can have multiple Aliases, meaning one fundamental identity can be represented by different external systems. For example, a human operator might have an LDAP alias and a GitHub alias, both pointing to the same Vault Entity.
Here’s how you might create an alias for an Entity. Let’s say we have an existing Entity ID e1234567-abcd-efgh-ijkl-0123456789ab.
# Authenticating via Kubernetes will create an alias if one doesn't exist for that service account.
# The vault write command above implicitly handles this.
# If you wanted to manually create an alias for an existing entity:
vault write identity/entity/id/e1234567-abcd-efgh-ijkl-0123456789ab \
alias/name=my-k8s-service-account \
alias/mount-accessor=<mount_accessor_for_k8s_auth_method> \
alias/metadata='{"namespace": "default"}'
Groups in Vault are collections of Entities. They provide a way to manage permissions and policies at a higher level. Instead of assigning policies to individual Entities, you can assign them to Groups, and then add Entities to those Groups. This dramatically simplifies policy management, especially in large environments. If you have a team of developers, you create a "developers" group, assign the necessary policies to that group, and then add each developer’s Entity to the "developers" group.
Consider a scenario where you want to grant access to a specific secret. You can create a Vault Group named app-admins.
# Create the group
vault write identity/group name=app-admins
# Assign a policy to the group (assuming 'secret-manager-policy' exists)
vault write identity/group/name/app-admins policies=secret-manager-policy
# Now, add an Entity ID to this group. Let's say entity ID is 'e1234567-abcd-efgh-ijkl-0123456789ab'
vault write identity/group/name/app-admins \
member_entity_ids=e1234567-abcd-efgh-ijkl-0123456789ab
When an identity authenticates, Vault establishes an Entity and associated Aliases. If that Entity is a member of any Groups, Vault aggregates the policies from all those Groups. The final set of policies applied to the authenticated token is the union of policies directly attached to the Entity and policies attached to any Groups the Entity belongs to. This layered approach provides immense flexibility.
The most surprising thing about Vault’s identity system is how it decouples authentication from authorization. An Entity isn’t inherently authorized for anything; it’s merely a subject. Authorization is entirely driven by the policies attached to its Aliases, its direct Entity, or the Groups it belongs to. This means you can authenticate a service using its cloud provider’s IAM role, but Vault doesn’t trust the IAM role itself for what it can do in Vault; it only uses it to identify the service and then grants permissions based on Vault’s internal policies.
The next concept you’ll likely encounter is how these Entities, Aliases, and Groups are used to drive dynamic secrets.