Learn to use the Vault UI

12min
|
Vault

All editions of Vault include a web user interface (UI). In this tutorial you will assume the role of Oliver from the operations team who is going to configure Vault using the UI for Steve and the SRE team.

Scenario

Steve will review how teams at HashiCups can use the Vault UI to manage and support the HashiCups Vault implementation.

Prerequisites

To complete this tutorial, you need the following:

Vault binary installed and configured in your system PATH.

Set up the lab

Open a terminal and start a Vault dev server with the literal string root as the root token value, and enable TLS.
```
$ vault server -dev -dev-root-token-id root -dev-tls
```
Root tokens
The dev mode server starts with an initial root token value set.
Root token use should be extremely guarded in production environments because it provides full access to the Vault server.
You can supply the root token value to start Vault in dev mode for convenience and to keep the tutorial steps focused on the learning goals of this tutorial.
Open a web browser and navigate to https://127.0.0.1:8200. Accept the warning about self-signed certificates.
Certificate errors
When you start Vault with the -dev-tls flag Vault generates self-signed certificates. Use of self-signed certificates and associated warnings can be expected during the tutorial.
Take certificate errors warnings seriously in real world scenarios to avoid a malicious actor attempting to intercept traffic.
The Vault UI loads and presents the sign in form.

Check the sever status

The Vault UI uses the Vault API as the basis for all operations. Anything that you do in the UI, has a corresponding API. The Vault API includes an unauthenticated endpoint to verify the status of the Vault server.

Validate the server status by opening a new browser/tab and navigating to https://127.0.0.1:8200/v1/sys/seal-status.
Navigate to the Vault login page at https://127.0.0.1:8200/ui.

Understand the Vault UI

All editions of Vault include the Vault UI. The Vault UI supports authenticating to Vault using supported auth methods such as userpass or oidc through an OIDC provider. Auth methods for application workloads such as kubernetes or a supported cloud provider is not supported in the UI.

When using HCP Vault, or a self-hosted Vault dev mode server, you do not have to enable the UI. When running a self-hosted Vault Enterprise or Community Edition server, you enable the UI in the Vault configuration file.

Because you are running Vault in dev mode, the UI is automatically enabled. This helps quickly start Vault for testing or developing.

You can enable the UI using a Vault configuration file for more complex requirements. Add the ui parameter to the configuration file and set the value to true.

Example:

ui            = true
cluster_addr  = "https://127.0.0.1:8201"
api_addr      = "https://127.0.0.1:8200"
...

Explore the Vault UI

On the Vault login page (https://127.0.0.1:8200/ui) enter root in the Token field and click Sign In.
The Vault Dashboard is the first page seen when logging into a Vault server. It provides useful information about the server (or cluster) such as enabled secrets engines, and Configuration details about the server.
Review the Configuration details card.
Notice that the UI reflects that you enabled TLS in the lab setup section when starting Vault. The configuration details also show the Storage type is set to inmem. This is the only storage option when starting Vault in dev mode. When the dev server is stopped, all configuration information is lost, because it is only stored in memory.

The primary navigation for the Vault UI is on the left side of the screen. This sidebar provides access to common Vault plugins such as Secrets Engines and auth methods using the Access menu. Vault UI with the left navigation sidebar
highlighted

The Vault UI is using a responsive interface. If you resize your browser, certain elements of the UI will shift, or in the case the left navigation sidebar, will close.

You can expand the navigation sidebar by clicking the double arrow (or caret) icon. Vault UI with the navigation sidebar closed because the browser has been
resized

When you access a Vault feature, the navigation sidebar will change to the relevant context for the feature you are accessing. You can return to the main navigation sidebar by clicking Back to main navigation. Vault UI showing the ACL policies page with the back to main navigation link
highlighted

Click on each of the tabs to learn more about the features available in the UI.

The user menu has two functions, to log out of the UI session or to copy the token issued by Vault when you authenticated.

The ability to copy the token can be useful when browsing the Vault UI, and wanting to shift testing to either the Vault API or Vault CLI.

Like the UI, both the API and CLI require you to authenticate with Vault. Instead of re-authenticating, you can copy the token from the UI and pass the token to either the CLI or API call.

The tools section provides access to several Vault features such as response wrapping, random string generator, and the API explorer. These tools are helpful when testing a workflow, or sharing one off data with another Vault user.

The wrap tool allows you to tokenize data into a single use token with a default 30 minute TTL that other Vault users can unwrap to retrieve the data. Because the token is single use, there is a limited window in which an unauthorized person can compromise the data. Vault UI showing the wrap tool with a sample JSON string before being
tokenized

If the intended party is unable to unwrap the token within the given TTL, you can trigger a security incident. You can set a custom TTL as required. If the intended party does not unwrap the token within the TTL, the token is no longer valid.

The lookup tool allows a Vault user with the token to verify information about the token without unwrapping the data. This allows the recipient to validate the token prior to retrieving the data.

The unwrap tool provides the ability to unwrap a wrapped token, exposing the data contained in the token. Vault UI showing the wrap tool with a sample JSON string before being
tokenized

Rewrap allows you to rewrap an unused token, generating a new token value and refreshing the TTL.

The random byte generator will generate a random string based on the requested number of bytes in either base64 or hex format.

The hash tool accepts data, encodes the value into a base64 string, and generates a hash value based on the desired algorithm and output format.

The API explorer provides local access to API documentation. This can be especially useful in highly secure, air-gapped environments that may not have access to the public Vault documentation. Vault UI showing the API explorer from the tools menu featuring several auth
API examples

Client count monitoring is an important task for Vault administrators. A client is anything that connects and authenticates to Vault. This could be a member of the operations team authenticating to configure a new secrets engine, a developer who needs to retrieve a secret, or a workflow such as the Vault Agent or a CI/CD pipeline requesting access to a hyperscaler to perform an application deployment. Vault UI showing the Vault usage metrics overview
dashboard

When using Vault Community Edition, this visibility is important to ensure the count of people or systems meets your expectations. For Vault Enterprise and HCP Vault Dedicated, this is also the primary metric.

Enable and configure an auth method

(Persona: Operations)

Oliver will use the Vault UI to enable and configure the userpass auth method for the SRE team, and create a Vault ACL policy to allow access to the k/v secrets engine.

Create ACL policy

Steve needs the ability to create, list, read, and update new key/value secrets at the path sre-secrets. ACL policies are expressed in HashiCorp Configuration Language (HCL).

Navigate to the main Vault dashboard at https://127.0.0.1:8200/ui/vault/dashboard and click Policies.
ACL policies allow you to define which paths, and actions, a user can perform in Vault. There are two default policies - root and default. The root policy provides full administrative access to Vault. This policy should be used only for initial configuration of Vault, or for emergency access.
Click Create ACL policy.
You can write a policy directly in the Vault UI, or upload a Vault policy written in HCL using the UI. In this tutorial you are using the UI to perform some Vault configuration. Even if the UI will be your primary interface to Vault, it is a good practice to store and manage Vault configuration such as policies as code and store them a version control system like Git.
Enter sre-secrets in the Name field.

Enter the following ACL policy in the Policy text box.

path "sre-secrets/+/creds" {
  capabilities = ["create", "list", "read", "update"]
}

Click Create policy.
Click Back to main navigation.
Click Access.
Click Enable new auth method.
Click Username & Password. The default path is set to userpass. You can enable the same auth method multiple times at different paths.
Leave the path set to userpass.
Click Enable method. There are multiple options available for most auth methods, such as overriding the TTL with the default lease value or changing the token type.
Leave the default options and click View method.
Click Create user.
Enter steve in the Username field, VauLtRul3z! in the Password field.
Expand Tokens and scroll down to the Generated Token's Policies field.
Enter sre-secrets and click Add
Click Save

In this section you assumed the role of Oliver and created a Vault ACL policy, configured the userpass auth method, and create an account to allow Steve to log in.

Enable and configure a secrets engine

(Persona: Operations)

Now that the userpass auth method has been configured, you will configure the k/v secrets engine to allow Steve to write static secret values to Vault.

Click Back to main navigation.
Click Secrets Engines.
Click Enable new engine.
Click KV. The default path is set to kv. Like auth methods, you can enable the same secrets engine multiple times at different paths.
Based on the policy you created, what path should the kv secret engine be enabled at?
In the Create ACL policy section, you created a policy that permits access to the path sre-secrets/+/creds. If you were to accept the default path of kv, Steve would not be able to read or write any secrets because the path would not match the path included in the policy.
You will have to change the default path from kv to sre-secrets for the policy to work.
Enter sre-secrets in the Path field.
Click Method Options.
Here you can configure additional secrets engine options. Options will vary from plugin to plugin. For the kv secrets engine you can choose between version 1 and version 2 of the plugin.
Leave all additional options set to their default values.
Click Enable engine.
Click the user menu and select Log out.

In this section you assumed the role of Oliver and enabled the kv secrets engine at a non-default path of sre-secrets. The path of the secret engine must match the path included in a policy.

Authenticate and create secrets

(Persona: SRE)

Now that Oliver has finished the Vault configuration, you will assume the role of Steve and log into Vault and access the kv secrets engine at the custom sre-secrets path.

On the Vault login page (https://127.0.0.1:8200/ui) click the Method pull down menu and select Username.
Enter steve in the Username field, then enter VauLtRul3z! in the Password field, and click Sign in.
Unlike the dashboard view when logging in with the root token, the Configuration card is not visible. Why do you think the configuration information is not visible?
When you log in with a root token, the `root policy provides full access to all configuration options.
When you log in as Steve, the only policies applied to token using from the userpass auth method configuration is default and sre-secrets which does not allow access to the Vault configuration.
Click sre-secrets.
Click Create secret.
In the Path for this secret enter creds.
In the Secret data field enter username in the key text box and steve-admin in the value text box.
Click Save.
The secret is now available in Vault. Steve, or any other Vault user with a policy that permits access to the sre-secrets path can retrieve the secret.

Clean up

Use CTRL+C to stop the server process in the terminal window where you started the server, or use this command to kill the server process from any local terminal session:

$ pkill vault

Summary

The Vault provides a UI to manage and consume Vault for use cases where the CLI or API is not an option. The Vault UI also supports browser based CLI with a subset of Vault commands specific to UI based workflows.

Learn to use the Vault CLI

Learn to use the Vault HTTP API