Welcome back! 

In this lecture we'll introduce you to Vault Authentication and the various options available to you for authenticating users. The agenda for this lecture will include the following, we'll discuss Vault tokens and how we can control their lifecycle, we'll examine specialized types of Vault tokens, such as: periodic, orphan, and use limited tokens. And we'll finish by reviewing the different Authentication methods available within Vault. 

In this section we'll review Vault Tokens the core method for tracking authenticated Vault sessions. Tokens are a key authentication component of Vault. Every operation performed within Vault requires the presence of an authentication token. No token, no access period. The token auth method is built-in and automatically available at /auth/token. It allows users to authenticate using a token, as well to create new tokens, revoke secrets by token, and more. When any other auth method returns an identity, Vault core invokes the token method to create a new unique token for that identity. Tokens are mapped to one or more Vault policies to control and authorize behavior within Vault. Almost everything in Vault has an associated lease, and when that lease is expired, the secret is revoked. This actually includes tokens as well. A token, if not renewed, will automatically expire. When a new token or secret is created, it is a child of its creator. If the parent is revoked or expires, then so do all of its children regardless of their own leases. A child may be a token, secret, or authentication created by a parent but a parent is almost always a token. Different parts of your environment will have differing token requirements. Consider the following three different token lifecycle scenarios. One, you have a long-running app which can not handle a regeneration of a token or secret. Two, you have a case where the lease's expiration is influenced by its parent and this is undesirable. Or three, you want to create a token which gets revoked automatically after one use known as a single-use token. As we'll shortly see, Vault can be configured to help with each of these requirements. Vault provides several different token types depending on requirement. Periodic Tokens which has no max TTL associated with them. Orphan Tokens which has no parent. And Use Limit Tokens which can only be used once. 

In this section we'll review how Vault tokens are created. Using the Vault CLI, tokens are created by running the command vault token create. Adding the dash h parameter will display the help and options available for the command. In this example we are creating a token with a TTL, or Time To Live of 24 hours, attaching it to the base policy and giving it a display name of test. Tokens can also be created by invoking the API endpoint auth token create. 

In this section we'll examine Periodic Tokens, and how they can be used for long running services. In some cases, revoking a token after a short period of time would be problematic. For instance, if a long-running service needs to maintain its SQL connection pool over a long period of time. In this scenario, a periodic token can be used. Periodic tokens can be created in a few ways, one of them is by having sudo capability or a root token with the auth/token/create endpoint. Another is by using token store roles. And a third is to use an auth method that supports issuing these, such as AppRole. Periodic tokens have a TTL, but no max TTL, meaning that their lifetime can be forever so long as they are renewed within their TTL. In summary, Periodic Tokens are useful in situations where long-running services cannot handle token renewals. Now creating a Periodic Token using the Vault CLI can be accomplished by running the command vault token create, and by setting the period parameter to a valid period, for example 24 hours. When this is done, the token becomes periodic, meaning that it has no max TTL. For example, creating a token with the period parameter set to 24 hours would require that the token to be continually renewed every 24 hours or 86400 seconds, for it to remain valid indefinitely. Consulting the vault token lookup command with an actual token provides a list of properties that the token exhibits. In the example shown here, we can see that the token is indeed a Periodic Token due to the fact that its period property is set to 24 hours represented in seconds. 

In this section we'll examine Orphan Tokens, and how they can exist in isolation, without any hierarchical relationship. Normally, when a token holder creates new tokens, these tokens will be created as children of the original token; and tokens they create will be children of them; and so on. When a parent token is revoked, all of its child tokens and all of their leases are revoked as well. Now this ensures that a user cannot escape revocation by simply generating a never-ending tree of child tokens but sometimes this behavior is not desired, so users with appropriate access can create orphan tokens. These tokens have no parent they are the root of their own token tree. These orphan tokens can be created in a number of ways. One, via the auth/token/create-orphan endpoint. Two, by having sudo capability or root policy when accessing auth/token/create and setting the orphan parameter to true. Three via token store roles. Four, by logging in with any other non-token auth method. Creating an Orphan Token using the Vault CLI can be accomplished by running the command vault token create, and by specifying the orphan parameter. When this is done, the token becomes an orphan, meaning that it has no parentage. In the example shown here, we can see that the token is indeed an Orphan Token due to the fact that its orphan property is set to true. 

In this section we'll examine Tokens that have a set use limit. It may be useful to limit the number of times a token can be presented back to Vault essentially limiting the number of times it can be used. Now tokens can be created with a set use limit. For example, you could create a token to be used only once, or you could create a token to be used a maximum of 10 times. A Use Limit token expires at the end of its last use, regardless of any remaining TTL on it. However, if a token whose lease has expired still has remaining uses available, that token still expires. Creating a Use Limit Token via the Vault CLI can be accomplished by running the command vault token create, and by specifying the use limit parameter with the number of uses to which it should be restricted. In the example shown here, we can see that the token use is limited to a maximum of two times, due to the fact that the num uses property is set to two. Using the same token from the previous slide, which has the num uses set to two, we see that the third attempt fails. 

In this section we will go through the process of Authentication and the various authentication methods that can be configured within Vault. Authentication is the process by which a user or machine-supplied identifying information is verified and converted into a Vault token with matching policies attached. The user or machine that authenticated then provides the Vault token back to Vault for any subsequent activity. In the example shown here Vault has been configured with the LDAP auth method. Users authenticate to Vault by providing their LDAP credentials and Vault passes these to the backend configured LDAP service for validation. If successful Vault generates a token, attaches a vault policy and returns to the user. Vault ships with several different authentication methods that can be enabled and configured depending on requirements and use cases. 

Let's review each of the methods. AppRole, which allows machines or apps to authenticate with Vault. AWS which provides an automated mechanism to retrieve a Vault token for AWS EC2 instances and IAM principals. Azure, which allows authentication against Vault using Azure Active Directory credentials. Google Cloud, which allows authentication against Vault using Google credentials. Kubernetes, which allows authentication against Vault using a Kubernetes Service Account Token. GitHub which allows authentication against Vault using a GitHub personal access token. LDAP, which allows authentication against an existing LDAP server and user/password credentials. Okta, which allows authentication using Okta and user/password credentials. RADIUS, which allows users to authenticate with Vault using an existing RADIUS server that accepts the PAP authentication scheme. TLS Certificates, which allows authentication using SSL/TLS client certificates which are either signed by a CA or self-signed. Tokens which are builtin and allows users to authenticate using a token, as well as to create new tokens, revoke secrets by token, and more. Username & Password, which allows users to authenticate with Vault using a username and password combination. 

The workflow for activating and configuring a Vault authentication method involves the following steps performed using the Vault CLI or API. First, activate the desired authentication method. Second, configure the authentication method which can differs per method. Third create and map policies to the authentication method. Setting up and configuring a new authentication method within Vault must be done by a privileged user who has been granted the necessary Vault permissions to do so. The following two examples demonstrate how to enable the github auth method by either using the Vault CLI or API. In doing so, this activates the github authentication mechanism and allows a user to authenticate by providing a GitHub personal access token. Having successfully activated a particular auth method, its configuration and behavior can be customized. For example, having activated the github auth method, as we did in the previous slide, we can continue by specifying and setting the associated organization attribute. In this case to hashicorp. When working with the Github auth method you may configure and map your github teams to specific Vault policies such that depending on your membership you'll be granted different permissions within Vault. This configuration pattern of mapping externally managed groups or teams to Vault policies is applicable to other Vault auth methods, for example the LDAP auth method. Using the Vault CLI, you can inspect what auth methods are currently enabled by executing the vault auth list command. This will display all the currently enabled auth methods. 

Getting help with a specific auth method can be achieved by running vault auth help with the name of the specific authentication method. Finally, once all of the specific auth method configuration is in place, you can go ahead and perform an authentication. Again using the Vault CLI, to authenticate you execute the command vault login setting the method parameter to the name of the auth type. You'll then be presented with a challenge specific to the auth method requiring you to provide identification. In this example, we are attempting to authenticate using the github auth method. We are challenged to provide a GitHub personal access token. Assuming the GitHub personal access token we submit is validated we are returned a Vault authentication token which we can then use for all subsequent Vault activity. 

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