Set up Vault

(Persona: Developer)

The dev server is a built-in, pre-configured server that is not useful for production, but is helpful if you want to use Vault in your local development environment.

1. Before you start the server, use the vault binary to print help with the -help flag.

   $ vault server -help
   

   Scroll to the Dev options section.

   Dev Options:
   
   -dev
         Enable development mode. In this mode, Vault runs in-memory and starts
         unsealed. As the name implies, do not run "dev" mode in production. The
         default is false.
   
   -dev-cluster-json=<string>
         File to write cluster definition to
   
   -dev-listen-address=<string>
         Address to bind to in "dev" mode. The default is 127.0.0.1:8200. This
         can also be specified via the VAULT_DEV_LISTEN_ADDRESS environment
         variable.
   
   -dev-no-store-token
         Do not persist the dev root token to the token helper (usually the local
         filesystem) for use in future requests. The token will only be displayed
         in the command output. The default is false.
   
   -dev-root-token-id=<string>
         Initial root token. This only applies when running in "dev" mode.
         This can also be specified via the VAULT_DEV_ROOT_TOKEN_ID environment
         variable.
   
   -dev-tls
         Enable TLS development mode. In this mode, Vault runs in-memory and
         starts unsealed, with a generated TLS CA, certificate and key. As the
         name implies, do not run "dev-tls" mode in production. The default is
         false.
   
   -dev-tls-cert-dir=<string>
         Directory where generated TLS files are created if `-dev-tls` is
         specified. If left unset, files are generated in a temporary directory.
   
   -dev-tls-san=<string>
         Additional Subject Alternative Name (as a DNS name or IP address)
         to generate the certificate with if `-dev-tls` is specified. The
         certificate will always use localhost, localhost4, localhost6,
         localhost.localdomain, and the host name as alternate DNS names,
         and 127.0.0.1 as an alternate IP address. This flag can be specified
         multiple times to specify multiple SANs.
   

   The dev server listens on the loopback interface at 127.0.0.1 on TCP port 8200 without TLS enabled by default. At runtime, the dev server also automatically unseals, and prints the unseal key and initial root token values to the standard output.

2. Open a terminal and start a Vault dev server with the literal string root as the root token value, and enable 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 steps here focused on the learning goals of this tutorial.

   $ vault server -dev -dev-root-token-id root -dev-tls
   

   The server starts and emits startup details, and some helpful suggestions to the standard output.

   ==> Vault server configuration:
   
   Administrative Namespace:
               Api Address: https://127.0.0.1:8200
                        Cgo: disabled
            Cluster Address: https://127.0.0.1:8201
      Environment Variables: BROWSER, EDITOR, FZF_DEFAULT_OPTS, GOPATH, GPG_TTY, HOME, LANG, LC_ALL, LESS, LESSOPEN, LOGNAME, LSCOLORS, LS_COLORS, MANPATH, NVM_BIN, NVM_CD_FLAGS, NVM_DIR, NVM_INC, OLDPWD, OS_ARCH, PAGER, PATH, PRODUCT, PWD, SHELL, SHLVL, SSH_AGENT_PID, SSH_AUTH_SOCK, STARSHIP_SESSION_KEY, STARSHIP_SHELL, TERM, TERM_PROGRAM, TERM_PROGRAM_VERSION, TERM_SESSION_ID, TMPDIR, USER, VERSION, VISUAL, XPC_FLAGS, XPC_SERVICE_NAME, ZDOTDIR, ZSH, ZSH_TMUX_CONFIG, ZSH_TMUX_TERM, _, _ZSH_TMUX_FIXED_CONFIG, __CFBundleIdentifier
               Go Version: go1.21.5
               Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", disable_request_limiter: "false", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
                  Log Level:
                     Mlock: supported: false, enabled: false
            Recovery Mode: false
            Request Limiter: disabled
                  Storage: inmem
                  Version: Vault v1.16.0-rc2, built 2024-02-20T22:43:58Z
               Version Sha: f85545f4f6488615859efe1c25b6b9e2b0fbaea3
   
   ==> Vault server started! Log data will stream in below:
   
   2024-04-04T13:24:07.248-0400 [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
   2024-04-04T13:24:07.251-0400 [INFO]  incrementing seal generation: generation=1
   2024-04-04T13:24:07.251-0400 [WARN]  no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set
   2024-04-04T13:24:07.257-0400 [INFO]  core: Initializing version history cache for core
   2024-04-04T13:24:07.258-0400 [INFO]  events: Starting event system
   2024-04-04T13:24:07.262-0400 [INFO]  core: security barrier not initialized
   2024-04-04T13:24:07.262-0400 [INFO]  core: security barrier initialized: stored=1 shares=1 threshold=1
   2024-04-04T13:24:07.272-0400 [INFO]  core: post-unseal setup starting
   2024-04-04T13:24:07.285-0400 [INFO]  core: loaded wrapping token key
   2024-04-04T13:24:07.285-0400 [INFO]  core: successfully setup plugin runtime catalog
   2024-04-04T13:24:07.285-0400 [INFO]  core: successfully setup plugin catalog: plugin-directory=""
   2024-04-04T13:24:07.290-0400 [INFO]  core: no mounts; adding default mount table
   2024-04-04T13:24:07.301-0400 [INFO]  core: successfully mounted: type=cubbyhole version="v1.16.0+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.317-0400 [INFO]  core: successfully mounted: type=system version="v1.16.0+builtin.vault" path=sys/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.325-0400 [INFO]  core: successfully mounted: type=identity version="v1.16.0+builtin.vault" path=identity/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.333-0400 [INFO]  core: successfully mounted: type=token version="v1.16.0+builtin.vault" path=token/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.334-0400 [INFO]  rollback: Starting the rollback manager with 256 workers
   2024-04-04T13:24:07.335-0400 [INFO]  rollback: starting rollback manager
   2024-04-04T13:24:07.337-0400 [INFO]  core: restoring leases
   2024-04-04T13:24:07.339-0400 [INFO]  identity: entities restored
   2024-04-04T13:24:07.339-0400 [INFO]  identity: groups restored
   2024-04-04T13:24:07.340-0400 [INFO]  expiration: lease restore complete
   2024-04-04T13:24:07.341-0400 [INFO]  core: Recorded vault version: vault version=1.16.0 upgrade time="2024-04-04 17:24:07.341637 +0000 UTC" build date=2024-02-20T22:43:58Z
   2024-04-04T13:24:07.345-0400 [INFO]  core: post-unseal setup complete
   2024-04-04T13:24:07.346-0400 [INFO]  core: root token generated
   2024-04-04T13:24:07.346-0400 [INFO]  core: pre-seal teardown starting
   2024-04-04T13:24:07.347-0400 [INFO]  rollback: stopping rollback manager
   2024-04-04T13:24:07.347-0400 [INFO]  core: pre-seal teardown complete
   2024-04-04T13:24:07.347-0400 [INFO]  core.cluster-listener.tcp: starting listener: listener_address=127.0.0.1:8201
   2024-04-04T13:24:07.347-0400 [INFO]  core.cluster-listener: serving cluster requests: cluster_listen_address=127.0.0.1:8201
   2024-04-04T13:24:07.348-0400 [INFO]  core: post-unseal setup starting
   2024-04-04T13:24:07.348-0400 [INFO]  core: loaded wrapping token key
   2024-04-04T13:24:07.348-0400 [INFO]  core: successfully setup plugin runtime catalog
   2024-04-04T13:24:07.348-0400 [INFO]  core: successfully setup plugin catalog: plugin-directory=""
   2024-04-04T13:24:07.350-0400 [INFO]  core: successfully mounted: type=system version="v1.16.0+builtin.vault" path=sys/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.351-0400 [INFO]  core: successfully mounted: type=identity version="v1.16.0+builtin.vault" path=identity/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.351-0400 [INFO]  core: successfully mounted: type=cubbyhole version="v1.16.0+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.352-0400 [INFO]  core: successfully mounted: type=token version="v1.16.0+builtin.vault" path=token/ namespace="ID: root. Path: "
   2024-04-04T13:24:07.352-0400 [INFO]  rollback: Starting the rollback manager with 256 workers
   2024-04-04T13:24:07.352-0400 [INFO]  rollback: starting rollback manager
   2024-04-04T13:24:07.352-0400 [INFO]  core: restoring leases
   2024-04-04T13:24:07.353-0400 [INFO]  expiration: lease restore complete
   2024-04-04T13:24:07.353-0400 [INFO]  identity: entities restored
   2024-04-04T13:24:07.353-0400 [INFO]  identity: groups restored
   2024-04-04T13:24:07.354-0400 [INFO]  core: post-unseal setup complete
   2024-04-04T13:24:07.354-0400 [INFO]  core: vault is unsealed
   2024-04-04T13:24:07.363-0400 [INFO]  expiration: revoked lease: lease_id=auth/token/root/h682dc4863bb61206a91b3ba7ebac7f38ce5a37e3f781538171b7f1dd1f360463
   2024-04-04T13:24:07.374-0400 [INFO]  core: successful mount: namespace="" path=secret/ type=kv version="v0.17.0+builtin"
   WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
   and starts unsealed with a single unseal key. The root token is already
   authenticated to the CLI, so you can immediately begin using Vault.
   
   You may need to set the following environment variables:
   
      $ export VAULT_ADDR='https://127.0.0.1:8200'
      $ export VAULT_CACERT='/var/folders/qr/zgztx0sj6n1dxy86sl36ntnw0000gn/T/vault-tls3037226588/vault-ca.pem'
   
   The unseal key and root token are displayed below in case you want to
   seal/unseal the Vault or re-authenticate.
   
   Unseal Key: 1kDP9lKLzPHZsTzc9TEel3FfclBmKNClhaDhAnDx2J8=
   Root Token: root
   
   Development mode should NOT be used in production installations!
   

   The first section lists Vault server configuration details. This information is helpful to confirm that the server is operating under your desired configuration.

   The second section shows server startup log output. This information relates to the operational status of the server during startup.

   Since this is a dev server, Vault adds some extra helpful suggestions to the output in the third section.

   You can use these suggestions to prepare your Vault client for communicating with the server.

3. In a new terminal, export the VAULT_ADDR and VAULT_CACERT environment variables using the commands suggested in your Vault dev server output. Copy each command (without the $) from the server output, and paste it into the new terminal session.

   Here is an example of the first export command that instructs the client to communicate with the dev mode server.

   export VAULT_ADDR='https://127.0.0.1:8200'
   

   Here is an example of the second command to specify the certificate authority file path.

   $ export VAULT_CACERT='/var/folders/qr/zgztx0sj6n1dxy86sl36ntnw0000gn/T/vault-tls3037226588/vault-ca.pem'
   

   Remember to use your dev server's values, not the examples shown here.

(Persona: operations)

Launch Terminal

This tutorial includes a free interactive command-line lab that lets you follow along on actual cloud infrastructure.

Start interactive lab

A dev server requires little configuration to use, but a self-managed Vault server needs configuration for networking, storage, and other Vault-specific options.

As the operations persona, your task here is to prepare a Vault server environment, TLS certificate and key material, and a configuration file for the server.

You can define Vault server configuration in HashiCorp Configuration Language (HCL) as a file or collection of files that the server reads at runtime.

You'll use the following example Vault server configuration file:

api_addr                = "https://127.0.0.1:8200"
cluster_addr            = "https://127.0.0.1:8201"
cluster_name            = "learn-vault-cluster"
disable_mlock           = true
ui                      = true

listener "tcp" {
address       = "127.0.0.1:8200"
tls_cert_file = "/tmp/vault-cert.pem"
tls_key_file  = "/tmp/vault-key.pem"
}

backend "raft" {
path    = "/tmp/vault-data"
node_id = "learn-vault-server"
}

Lines 1 through 5 are global options:

1. api_addr: the server API address is what all clients connect to for interacting with Vault, and formatted as a URL with a port number.

2. cluster_addr: the server cluster address, required for intra-cluster communication between Vault servers participating in a cluster. This address is also expressed as a URL with port.

3. cluster_name: the server cluster name is the same for all servers participating in a cluster.

4. disable_mlock: for servers which use integrated storage, disable operating system memory locking for the Vault process, as it can cause undesired behavior with the integrated storage backend. Disable memory locking by setting this option's value to true.

5. ui: If you want to use the Vault web user interface, you must explicitly enable it. Enable the Vault UI by setting this option's value to true.

Lines 7 through 11 are part of the listener stanza, and define how and where the Vault server listens for incoming connections. Vault can listen on TCP ports or Unix domain sockets.

In this example, the server address is the loopback interface at address 127.0.0.1 with the TCP port 8200. When you define a TCP port listener, the server expects TLS enabled by default. You must then also configure tls_cert_file and tls_key_file by setting their values to the fully qualified path to a valid TLS certificate and key file respectively.

Lines 13 through 16 are part of the storage stanza, and define which type of storage backend the server uses, along with related options.

In this example, the server uses the storage type raft (integrated storage) while specifying the required local data storage path and node identifier.

You've learned about the configuration you'll use with the self-managed Vault server, and now you're ready to prepare and start the server.

1. Create a directory for storing the server data.

   $ mkdir /tmp/vault-data
   

2. Use openssl to generate a self-signed TLS certificate and key for the server to use, and write them to the files /tmp/vault-cert.pem and /tmp/vault-key.pem.

   $ openssl req -x509 -newkey rsa:4096 -sha256 -days 365 \
       -nodes -keyout /tmp/vault-key.pem -out /tmp/vault-cert.pem \
       -subj "/CN=localhost" \
       -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"
   

3. Create a basic server configuration file at the path /tmp/vault-server.hcl.

   $ cat > /tmp/vault-server.hcl << EOF
   api_addr                = "https://127.0.0.1:8200"
   cluster_addr            = "https://127.0.0.1:8201"
   cluster_name            = "learn-vault-cluster"
   disable_mlock           = true
   ui                      = true
   
   listener "tcp" {
   address       = "127.0.0.1:8200"
   tls_cert_file = "/tmp/vault-cert.pem"
   tls_key_file  = "/tmp/vault-key.pem"
   }
   
   backend "raft" {
   path    = "/tmp/vault-data"
   node_id = "learn-vault-server"
   }
   EOF
   

4. Start the server, and specify the full path to the server configuration file.

   $ vault server -config=/tmp/vault-server.hcl
   

   The server starts, and streams information to the standard output as shown in this example:

   ==> Vault server configuration:
   
   Administrative Namespace:
               Api Address: https://127.0.0.1:8200
                        Cgo: disabled
            Cluster Address: https://127.0.0.1:8201
      Environment Variables: BROWSER, EDITOR, FZF_DEFAULT_OPTS, GOPATH, GPG_TTY, HOME, LANG, LC_ALL, LESS, LESSOPEN, LOGNAME, LSCOLORS, LS_COLORS, MANPATH, NVM_BIN, NVM_CD_FLAGS, NVM_DIR, NVM_INC, OLDPWD, PAGER, PATH, PWD, SHELL, SHLVL, SSH_AGENT_PID, SSH_AUTH_SOCK, STARSHIP_SESSION_KEY, STARSHIP_SHELL, TERM, TERM_PROGRAM, TERM_PROGRAM_VERSION, TERM_SESSION_ID, TMPDIR, USER, VAULT_ADDR, VAULT_SKIP_VERIFY, VISUAL, XPC_FLAGS, XPC_SERVICE_NAME, ZDOTDIR, ZSH, ZSH_TMUX_CONFIG, ZSH_TMUX_TERM, _, _ZSH_TMUX_FIXED_CONFIG, __CFBundleIdentifier
               Go Version: go1.21.8
               Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", disable_request_limiter: "false", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
                  Log Level:
                     Mlock: supported: false, enabled: false
            Recovery Mode: false
                  Storage: raft (HA available)
                  Version: Vault v1.16.1, built 2024-04-03T12:35:53Z
               Version Sha: 6b5986790d7748100de77f7f127119c4a0f78946
   
   ==> Vault server started! Log data will stream in below:
   
   2024-04-18T11:39:14.675-0400 [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
   2024-04-18T11:39:14.743-0400 [INFO]  incrementing seal generation: generation=1
   2024-04-18T11:39:14.748-0400 [INFO]  core: Initializing version history cache for core
   2024-04-18T11:39:14.748-0400 [INFO]  events: Starting event system
   

   The first section lists Vault server configuration details. This information is helpful to confirm that the server is operating under your desired configuration.

   The second section shows server startup log output. This information relates to the operational status of the server during startup.

   Before you can use the server, you must first initialize and unseal it. For this tutorial, you can initialize Vault with the default Shamir's Secret Sharing seal, but specify just 1 key share and a key threshold of 1.

   This means that you can unseal Vault in the next step with just one key share instead of the default 3 of 5 key shares.

5. In a new terminal session, export the VAULT_ADDR environment variable to address the server.

   $ export VAULT_ADDR=https://127.0.0.1:8200
   

6. Vault uses strict verification of all TLS certificates by default. Since you're using a self-signed TLS certificate without a certificate authority, you should disable this strict checking by exporting the VAULT_SKIP_VERIFY environment variable and setting its value to true.

   $ export VAULT_SKIP_VERIFY=true
   

7. Initialize the server.

   $ vault operator init -key-shares=1 -key-threshold=1
   

   Vault responds to your initialization request with output containing the unseal key value and initial root token value as shown in this example.

   Unseal Key 1: HLOCX7/wwvFg10EMvT9Zfa+5HfiPjKTaJRub06PDMnc=
   
   Initial Root Token: hvs.YOo2eCJlbW3wKIKtj9lHSoz4
   
   Vault initialized with 1 key shares and a key threshold of 1. Please securely
   distribute the key shares printed above. When the Vault is re-sealed,
   restarted, or stopped, you must supply at least 1 of these keys to unseal it
   before it can start servicing requests.
   
   Vault does not store the generated root key. Without at least 1 keys to
   reconstruct the root key, Vault will remain permanently sealed!
   
   It is possible to generate new unseal keys, provided you have a quorum of
   existing unseal keys shares. See "vault operator rekey" for more information.
   

   Tip

   You must initialize Vault to configure it for use. You do this just once, when the server is started against a new storage backend. When you run Vault in HA mode, you initialize once per cluster, not once per server. Vault generates the encryption keys, unseal keys, and the initial root token during initialization.

8. Every initialized Vault server starts in the sealed state. Vault can access the physical storage backend, but it can't read any of it because it doesn't know how to decrypt it. After you unseal Vault, it can read and write encrypted values in the storage backend.

   You can unseal the server with vault operator unseal and pass in the unseal key value as an argument to the command, but in this example you'll just use the command.

   $ vault operator unseal
   

   Vault responds to the command without arguments by prompting you for the unseal key.

   Unseal Key (will be hidden):
   

   Copy the Unseal Key 1: value from the initialization output, paste it at the prompt for unseal key and press RETURN.

   Vault responds by unsealing, and showing the server status.

   Key                     Value
   ---                     -----
   Seal Type               shamir
   Initialized             true
   Sealed                  false
   Total Shares            1
   Threshold               1
   Version                 1.16.1
   Build Date              2024-04-03T12:35:53Z
   Storage Type            raft
   Cluster Name            learn-vault-cluster
   Cluster ID              8bbda9de-6f92-1a6c-90d5-925b6e88c3c3
   HA Enabled              true
   HA Cluster              n/a
   HA Mode                 standby
   Active Node Address     <none>
   Raft Committed Index    29
   Raft Applied Index      29
   

(Persona: operations)

1. Launch the HCP Portal and login.

   If you have logged in before, the portal opens the last project you were in. Navigate back to the organization level from the breadcrumbs, or click on the HashiCorp icon at the top-left to choose another organization.

2. Click on the HashiCorp icon to list your organizations, and select the organization in which you'll create your HCP Vault Dedicated cluster.

   HashiCorp Cloud Platform (HCP) provides your account with an organization. Your account may invite others to join your organization or you may be invited to join other organizations.

3. Click Projects, and select the target project.

   If you don't have a project

   1. Click + Create project.
   2. Enter the Project name and Project description.
   3. Click Create project to complete.

   You can use projects to separate access within an organization, such as by team, use cases, or environment (e.g. development, staging, production, etc.).

4. From the Overview page, click Get started with Vault Dedicated.

   

5. From the Vault overview page you have the option to deploy HCP Vault Dedicated using a pre-configured template that deploys Vault with a sample configuration or you can choose to Start from scratch to deploy a standard Vault Dedicated instance with no existing configuration.

   For the purposes of this tutorial and learning about Vault, click the Create cluster button under Start from scratch.

   

6. Select your preferred cloud provider.

   

7. Click the Vault tier pull down menu and select Development.

   Tip

   The development tier should not be used for production workloads.

8. Click the Cluster size pull down menu and select Extra Small.

   For the development tier, Extra Small is the only available cluster size.

9. Under the Network section, accept or edit the Network ID, Region selection, and CIDR block for the HVN.

10. Under the Basics section, accept or edit the default Cluster ID (vault-cluster).

    

11. Under Templates, select Start from scratch. Templates provide sample configurations for various use cases.

12. Click Create cluster.

13. Wait for the cluster to initialize before proceeding.

    

14. After the cluster is created, refresh the page.

15. Click Cluster networking. The cluster networking page allows you to configure whether the cluster is configured for public or private access.

    By default, all development tier clusters are configured for public access and all production tier clusters are configured for private access.

    The IP Allow list allows you to add specific IP addresses or CIDR ranges that will be permitted to access the HCP Vault clusters public endpoint (if public access is enabled).

    You can also enable or disable the HCP Proxy. The proxy allows you to access the Vault user interface when private access is enabled.

16. Click Overview to return to the Vault cluster overview page.

The Vault page displays the created Vault cluster. Within that view, the Overview page displays information to help you learn about HCP Vault, Vault configuration, Vault usage, and cluster details. The Access Vault pane contains details that enable you to administer the Vault cluster through the Web UI or command-line interface (CLI).

Now that you have created a new HCP Vault instance, you will need to perform some initial configuration to support your use case such as enabling secrets engines to store or generate secrets, or adding additional auth methods to allow users or applications to authenticate with HCP Vault.

HCP Vault provides the same type of access as a traditional Vault cluster. You can access it through a command line interface (CLI) using the Vault binary, through the Vault API using common programming languages or tools such as cURL, or by using the Vault User Interface (UI).

Access the Vault cluster

1. Under Quick actions, click Command-line (CLI).

   

2. Click the copy button under Use public URL to copy the commands to export the correct VAULT_ADDR and VAULT_NAMESPACE values to the system Clipboard.

   

3. In a terminal, paste the copied commands.

   $ export VAULT_ADDR="https://vault-cluster-hashicups-operations-public-vault-c0ff331a.1d58aa23.z0.hashicorp.cloud:8200"; export VAULT_NAMESPACE="admin"
   

You're now ready to check the server status.

(Persona: developer)

Check the status of your Vault dev server.

$ vault status

Example output:

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.16.0
Build Date      2024-02-20T22:43:58Z
Storage Type    inmem
Cluster Name    vault-cluster-eabfb52b
Cluster ID      6150648b-ed4d-4e5f-8927-223137b0507b
HA Enabled      false

(Persona: operations)

Check the status of your Vault server.

$ vault status

Example output:

Key                     Value
---                     -----
Seal Type               shamir
Initialized             true
Sealed                  false
Total Shares            1
Threshold               1
Version                 1.16.1
Build Date              2024-04-03T12:35:53Z
Storage Type            raft
Cluster Name            learn-vault-cluster
Cluster ID              8bbda9de-6f92-1a6c-90d5-925b6e88c3c3
HA Enabled              true
HA Cluster              https://127.0.0.1:8201
HA Mode                 active
Active Since            2024-04-18T11:49:39.87382-04:00
Raft Committed Index    56
Raft Applied Index      56

(Persona: operations)

Check the status of your HCP Vault Dedicated server.

$ vault status

Example output:

Key                      Value
---                      -----
Seal Type                awskms
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    1
Threshold                1
Version                  1.15.5+ent
Build Date               2024-01-26T21:04:45Z
Storage Type             raft
Cluster Name             vault-cluster-a998d6c8
Cluster ID               b8c0ff33-a0cd-e74d-9c15-430ec1bb5e17
HA Enabled               true
HA Cluster               https://172.25.16.84:8201
HA Mode                  active
Active Since             2024-04-18T17:08:16.431186562Z
Raft Committed Index     2111
Raft Applied Index       2111
Last WAL                 732

Your HCP Vault Dedicated server is initialized and unsealed. By default Vault enables the token authentication method.

(Persona: developer)

Authenticate with Vault using the initial root token value.

$ vault login root

Vault prompts you for the token value:

Token (will be hidden):

Type in the literal string root, and press RETURN.

Vault responds with a success message, and output containing the token value and metadata.

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                hvs.Iz85NhcoJ9yl3q9q0FiBqd65
token_accessor       Xph6WI0roJRmLmVuM8J9Akky
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

(Persona: operations)

Authenticate with Vault using the initial root token value from the initialization output.

$ vault login

Vault prompts you for the token value:

Token (will be hidden):

Copy the Initial Root Token value from the initialization output, and paste it at the prompt.

Vault responds with a success message, and output containing the token value and metadata.

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                hvs.Iz85NhcoJ9yl3q9q0FiBqd65
token_accessor       Xph6WI0roJRmLmVuM8J9Akky
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

(Persona: operations)

1. Return to the Overview page and click Generate token.

   

   Within a few moments a new token is generated.

2. Copy the Admin Token.

   

3. Return to the terminal and login with Vault. When prompted, enter the generated admin token.

   $ vault login
   Token (will be hidden): <token>
   

   The <token> placeholder represents the copied token value.

   Example output:

   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   
   token                hvs.QRSTUV-WXypd-96-ANTSChh5sqa5IB4ZVQ0Qo_iLBWaNIbnQGiYKImh2cy5raE1qZmtBd2lzTkJ3bExITjVZcjRhbFMuSjlxNGcQeg
   token_accessor       CDeirnF8ijVMtkckQozs4hdk.J9q4g
   token_duration       5h19m35s
   token_renewable      false
   token_policies       ["default" "hcp-root"]
   identity_policies    []
   policies             ["default" "hcp-root"]
   

(Persona: developer)

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

Unset environment variables.

$ unset VAULT_ADDR VAULT_CACERT

(Persona: operations)

1. 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
   

2. Remove the Vault data directory.

   $ rm -rf /tmp/vault-data
   

3. Remove the server configuration file.

   $ rm -f /tmp/vault-server.hcl
   

4. Remove the TLS files.

   $ rm -f  /tmp/vault-cert.pem /tmp/vault-key.pem
   

5. Unset environment variables.

   $ unset VAULT_ADDR VAULT_SKIP_VERIFY
   

(Persona: operations)

1. Unset environment variables.

   $ unset VAULT_ADDR VAULT_NAMESPACE