Welcome back!

In this lecture, we'll review Vault Identities, in particular, Entities and Groups, and how they are used to manage authorization within Vault. The agenda for this lecture includes a review of Entities and Entity Aliases, the workflow required to create Entities and Entity Aliases with examples, and a review of Groups and Group Aliases, including Identity Groups, Group Hierarchical Permissions, and Internal Groups versus External Groups. 

In this section, we'll review Entity and Entity Aliases, and what problems they solve. The Identity secrets engine is the identity management solution within Vault. It internally maintains the clients who are recognized by Vault. Each client is internally termed as an Entity and an Entity can have multiple Aliases. For example, a single user who has two accounts in both GitHub and LDAP can be mapped to a single entity in Vault that has two aliases, one of type GitHub and one of type LDAP. When a client authenticates against a credential backend, Vault creates a new entity and attaches a new alias to it, if a corresponding entity doesn't already exist. The entity identifier will be tied to the authenticated token. When such tokens are put to use, their entity identifiers are audit logged, marking a trail of actions performed by specific users. Entities are single, logical identities that represent users and applications for the tokens that have been generated when authenticating via an auth backend. 

For example, a user may have AWS credentials as well as LDAP or Active Directory credentials. These separate credentials, known as Aliases within Vault Identity, and all of the tokens generated by these credentials, are all recognized as referring to the single user or application within the various parts of Vault. Vault simplifies administration across multiple Identity Providers, or IDPs, by bridging them into one common identity. Vault will automatically create an Entity if one does not exist for any client gaining access to a secret within Vault. Entities can have policies assigned to them that apply to all tokens associated with that entity. Vault policies can be assigned to entities, which will grant additional permissions to the token on top of the existing policies on that token. If the token presented on the API request contains an identifier for the entity, and if that entity has a set of policies on it, then the token will be capable of performing actions allowed by the policies on the entity as well. 

In this section, we'll review how Entities and Entity Aliases are created and managed. The Vault Identity store allows administrators to manage entities within Vault. Entities can be created and aliases can be tied to entities. The typical workflow for creating an Entity and/or Entity Aliases involves the following steps. First, by enabling a Vault auth method, a corresponding auth method mount_accessor will be generated. Next, an Entity can be created using the identity/entity endpoint and this, in turn, generates an Entity ID. Finally, an Entity Alias can be created by passing in the following parameters: name, which is the identifier of the client in the auth source, for example, a GitHub username, canonical_id, which is the identity to which the alias belongs, mount_accessor, which is the accessor of the auth method mount, and metadata, which is any metadata to be associated with the alias. 

Let's walk through an example where we'll enable the GitHub auth method and then create an Entity and Entity Alias. In step one, we begin by enabling the GitHub auth method, we do so by running the command vault auth enable github. Next, we configure the GitHub auth method, setting up the organization property to Hashicorp, and complete the configuration by mapping the users and/or teams within that GitHub organization to policies in Vault. In this case, the training team is mapped to the training policy. Next, we inspect the currently enabled auth methods, which now includes the GitHub auth method we enabled and configured in the previous slide. In this example, we run the command vault auth list with the format parameter set to JSON, and pipe the results through the powerful JQ utility. We are using JQ to format and color code the JSON output. Within this output, take note of the accessor value. In step two, we'll create an Entity. We do so by writing to the identity/entity endpoint. Here we are setting the name of the new entity to james and associate it with the base policy. The outcome of running this command is the creation of a new Entity with the corresponding Entity ID presented back to us. We can inspect any existing Entities by running the command vault read against the endpoint identity/entity/id and the Entity ID of the entity we are interested in. In step three, we'll create our Entity Alias. We do so by running the command vault write against the endpoint identity/entity-alias, passing in the alias name parameter, which in this case is jsmith, the canonical_id set to the Entity Id established in step two, and finally setting the mount_accessor parameter set to the value we inspected on using the JQ utility in step one. Running this command will create an Entity Alias for jsmith connected back to the Entity james, and this makes sense, as both identities are for the same person. 

In this section, we'll go over Groups and Group Aliases. Organizations tend to have some form of internal structure. Structure can be based on business units that exist within the business. Staff are then grouped within these business units. Some staff may participate within and across multiple business units, and each business unit will have a different set of compute resources that need to be managed. Org structures are typically maintained within LDAP services, such as Active Directory. The question from here is, how can we pull in and leverage group memberships held externally and use them to provide access control within Vault? The answer is to use Vault Identity Groups. Vault's Identity system has support for groups. A group can contain multiple entities as its members. A group can also have subgroups. Policies set on the group are granted to all members of the group. During request time, when the token's Entity ID is being evaluated for the policies that it has access to, along with the policies on the entity itself, policies that are inherited due to group memberships are also granted. 

Vault's Identity system also contains the ability to manage organizations of entities in groups. Groups can be internal groups, which are managed directly within Vault, or external groups, which are sourced from external identity providers. At authentication time, external group information for a user is returned to Vault, which can automatically categorize users into appropriate groups within Vault's Identity system. Similarly to entities, groups can be used to assign policies and metadata. Groups can contain direct entity members and can also contain other groups. This allows for major enhancements to automation by using Identity Groups to quickly and easily grant access to secrets and functionality within Vault. When working with Vault entities and groups, it's important to understand how policy permissions are hierarchical and therefore inherited. In the example shown here, the token has the base policy attached. The holder of this token happened to be a member of the Entity A. Entity A happened to be a member of the Security Group. Therefore, in this scenario, the token carries the capabilities granted by the base, DevOps, and SRE policies. An Identity Group Alias is used to maintain a mapping between a Vault Identity Group and a group held externally by a third party authentication provider. If a user is a member of an external group, such as an LDAP group, then the user will be automatically added to the Vault Identity Group, assuming the group alias is in place, and therefore will inherit the policies and metadata associated with the Vault's Identity Group. 

In this section, we'll review how Groups and Group Aliases are created and managed. Let's walk through an example where we'll create both internal and external groups. We'll start by creating an Internal Group. We do so by running the command vault write against the endpoint identity/group, and by specifying the name of the group, setting its type to internal, and attaching any applicable policies. Additionally, member entities can be added at time of creation. We can inspect any existing groups by running the command vault read against the endpoint identity/group/id and the group id of the group we are interested in. Next, let's create an External Group. We do so by running the command vault write against the endpoint identity/group and specifying the name of the group, but this time, we set its type to external and attach any applicable policies. 

When creating an external group, you do not specify the member entities or groups at time of creation. Finally, we create a Group Alias to connect the external group we created in the previous slide to our third party authentication provider, in this case, GitHub. To complete this setup, we invoke the command vault write against the endpoint identity/group-alias, specifying the group alias name, the mount_accessor to the GitHub auth method, and the canonical_id to the external group ID presented to us in the previous slide. 

Okay, that completes this lecture on Vault Identity. Go ahead and close this lecture and we'll see you shortly in the next one.