https://learn.hashicorp.com/vault/getting-started/installDocs https://www.vaultproject.io/docs
vault secrets list
vault kv list secret/
vault kv get secret/hello
https://learn.hashicorp.com/vault/getting-started/install
https://www.vaultproject.io/downloads.html
Verify
vault
To install completions, run:
vault -autocomplete-install
exec $SHELL
https://learn.hashicorp.com/vault/getting-started/dev-server
Vault operates as a client/server application.
To start the Vault dev server, run:
vault server -dev
Look for the following lines:
$ export VAULT_ADDR='<http://127.0.0.1:8200'>
Unseal Key: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0=
Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6x :warning: Do not run a dev server in production!
With the dev server running, do the following four things before
anything else:
export VAULT_ADDR='VAULT_ADDR'$ export VAULT_DEV_ROOT_TOKEN_ID="ROOT_TOKEN"
vault status
https://learn.hashicorp.com/vault/getting-started/first-secret
Using CLI https://www.vaultproject.io/docs/commands here, but can also HTTP API https://www.vaultproject.io/api/index.html
Using inmem backend in -dev but can use Consul https://www.consul.io/
write a secret
vault kv put secret/hello foo=world
You can even write multiple pieces of data, if you want:
vault kv put secret/hello foo=world excited=yes
command documentation https://www.vaultproject.io/docs/commands/index.html
The documentation uses the key=value based entry throughout, but it
is more secure to use files if possible. Sending data via the CLI is often
logged in shell history. For real secrets, please use files. See the link above
about reading in from STDIN.
read secret
vault kv get secret/hello
To print only the value of a given field:
vault kv get -field=excited secret/hello
Optional json output
vault kv get -format=json secret/hello | jq -r .data.data.excited
delete a secret
vault kv delete secret/hello
https://learn.hashicorp.com/vault/getting-started/secrets-engines
By default, Vault enables Key/Value version2 secrets engine
https://www.vaultproject.io/docs/secrets/kv/kv-v2/ at the path secret/ when
running in dev mode.
enable a new kv Secrets Engine https://www.vaultproject.io/docs/secrets
vault secrets enable -path=kv kv
Each path is completely isolated and cannot talk to other paths.
For example, a kv secrets engine enabled at foo has no ability to
communicate with a kv secrets engine enabled at bar.
:
If -path is not specified it defaults. This is same as above.
vault secrets enable kv
To verify our success and get more information about the secrets engine
vault secrets list
Path Type Accessor Description
---- ---- -------- -----------
cubbyhole/ cubbyhole cubbyhole_78189996 per-token private secret storage
identity/ identity identity_ac07951e identity store
kv/ kv kv_15087625 n/a
secret/ kv kv_4b990c45 key/value secret storage
sys/ system system_adff0898 system endpoints used for control, policy and debugging
The sys/ path corresponds to the system backend. These paths
interact with Vault’s core system and are not required for beginners.
To create secrets, use the kv put command.
vault kv put kv/hello target=world
Success! Data written to: kv/hello :ship: To read the secrets stored in the `kv/hello` path ```bash vault kv get kv/hello ```
===== Data =====
Key Value
--- -----
target world
Create secrets at the kv/my-secret path.
vault kv put kv/my-secret value="s3c(eT"
Read the secrets at kv/my-secret.
vault kv get kv/my-secret
Delete the secrets at kv/my-secret.
vault kv delete kv/my-secret
List existing keys at the kv path.
vault kv list kv/
Keys
----
hello
When a secrets engine is disabled, all secrets are revoked and the
corresponding Vault data and configuration is removed.
Disable engine
vault secrets disable kv/
this command takes a PATH to the secrets engine as an argument,
not the TYPE of the secrets engine.
Vault behaves similarly to a virtual filesystem https://en.wikipedia.org/wiki/Virtual_file_system
This abstraction is incredibly powerful. It enables Vault to interface directly with physical systems, databases, HSMs, etc. But in addition to these physical systems, Vault can interact with more unique environments like AWS IAM, dynamic SQL user creation, etc. all while using the same read/write interface.
https://learn.hashicorp.com/vault/getting-started/dynamic-secrets
Unlike the kv secrets where you had to put data into the store yourself,
dynamic secrets are generated when they are accessed.
Dynamic secrets do not exist until they are read, so there is no risk of someone stealing them or another client using the same secrets.
Because Vault has built-in revocation mechanisms, dynamic secrets can be revoked immediately after use, minimizing the amount of time the secret existed.
Before starting this page, please register for an
AWS account https://aws.amazon.com/
Enable aws secrets engine at aws/
vault secrets enable -path=aws aws
In this case, the AWS secrets engine generates dynamic, on-demand
AWS access credentials.
After enabling the AWS secrets engine, you must configure it to authenticate and communicate with AWS. This requires privileged account credentials. If you are unfamiliar with AWS, use your root account keys.
Do not use your root account keys in production. This is a getting started guide and is not a best practices guide for production installations.
I created an
[administrator credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html).
and copied keys into ~/.aws/credentials
configure AWS secrets engine with
vault write aws/config/root \
access_key=aws_access_key_id \
secret_key=aws_secret_access_key \
region=us-east-1
The next step is to configure a role. Vault knows how to create an IAM user via the AWS API, but it does not know what permissions, groups, and policies you want to attach to that user. This is where roles come in - a role in Vault is a human-friendly identifier to an action.
For example, here is an IAM policy https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html that enables all actions on EC2, but not IAM or other AWS services.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1426528957000",
"Effect": "Allow",
"Action": ["ec2:*"],
"Resource": ["*"]
}
]
}
We need to map this policy document to a named role https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
Map the above IAM policy to a new role my-role for user iam_user
vault write aws/roles/my-role \
credential_type=iam_user \
policy_document=-<<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1426528957000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
]
}
]
}
EOF
ask Vault to generate an access key pair for the new role
vault read aws/creds/my-role
Success! The access and secret key can now be used to perform any EC2 operations within AWS.
If you were to run the command a second time, you would get a new
access key pair. Each time you read from aws/creds/:name, Vault will connect
to AWS and generate a new IAM user and key pair.
Copy the full path of this lease_id value found in the output. This
value is used for renewal, revocation, and inspection.
Vault will automatically revoke this credential after 768 hours
(see lease_duration in the output)
To revoke the secret, use vault revoke with the lease ID that was
outputted from vault read when you ran it
vault lease revoke LEASE_ID
You’ve now worked with vault write and vault read for multiple paths: the kv secrets engine with kv/ and dynamic AWS credentials with the AWS secrets engine provider at aws/. In both cases, the structure and usage of each secrets engines differed, for example the AWS backend has special paths like aws/config.
Instead of having to memorize or reference documentation constantly to determine what paths to use, Vault has a built-in help system. This help system can be accessed via the API or the command-line and generates human-readable help for any path.
https://learn.hashicorp.com/vault/getting-started/help
This section assumes you have the AWS secrets engine enabled at aws/. If you
do not, enable it before continuing:
vault secrets enable -path=aws aws
With the secrets engine enabled, learn about it with the vault path-help command:
vault path-help aws
### DESCRIPTION
The AWS backend dynamically generates AWS access keys for a set of
IAM policies. The AWS access keys have a configurable lease set and
are automatically revoked at the end of the lease.
After mounting this backend, credentials to generate IAM keys must
be configured with the "root" path and policies must be written using
the "roles/" endpoints before any access keys can be generated.
### PATHS
The following paths are supported by this backend. To view help for
any of the paths below, use the help command with any route matching
the path pattern. Note that depending on the policy of your auth token,
you may or may not be able to access certain paths.
^config/lease$
Configure the default lease information for generated credentials.
^config/root$
Configure the root credentials that are used to manage IAM.
^creds/(?P<name>\w+)$
Generate an access key pair for a specific role.
^roles/(?P<name>\w+)$
Read and write IAM policies that access keys can be made for.
The vault path-help command takes a path. By specifying a root path, it will give us the overview of that secrets engine. Notice how the help not only contains a description, but also the exact regular expressions used to match routes for this backend along with a brief description of what the route is for.
After seeing the overview, we can continue to dive deeper by getting help for an individual path. For this, just use vault path-help with a path that would match the regular expression for that path. Note that the path doesn’t need to actually work. For example, we’ll get the help below for accessing aws/creds/my-non-existent-role, even though we never created the role:
vault path-help aws/creds/my-non-existent-role
Request: creds/my-non-existent-role
Matching Route: ^creds/(?P<name>\w(([\w-.]+)?\w)?)$
Generate an access key pair for a specific role.
### PARAMETERS
name (string)
Name of the role
### DESCRIPTION
This path will generate a new, never before used key pair for
accessing AWS. The IAM policy used to back this key pair will be
the "name" parameter. For example, if this backend is mounted at "aws",
then "aws/creds/deploy" would generate access keys for the "deploy" role.
The access keys will have a lease associated with them. The access keys
can be revoked by using the lease ID.
Within a path, we are given the parameters that this path requires. Some parameters come from the route itself. In this case, the name parameter is a named capture from the route regular expression. There is also a description of what that path does.
Go ahead and explore more paths! Enable other secrets engines, traverse their help systems, and learn about what they do.
The help system may not be the most exciting feature of Vault, but it is indispensable in day-to-day usage. The help system lets you learn about how to use any backend within Vault without leaving the command line.> Users can authenticate to Vault using multiple methods.
https://learn.hashicorp.com/vault/getting-started/authentication
When starting the Vault server in dev mode, it automatically logs
you in as the root user with admin permissions. In a non-dev setup, you would
have had to authenticate first.
Authentication is the mechanism of assigning an identity to a Vault user.
The access control and permissions associated with an identity are authorization https://learn.hashicorp.com/vault/getting-started/policies)
Vault has pluggable auth methods https://www.vaultproject.io/docs/auth
Token authentication is enabled by default in Vault and cannot be disabled.
When you start a dev server with vault server -dev, it prints your root
token. The root token is the initial access token to configure Vault. It has
root privileges, so it can perform any operation within Vault.
Create more tokens using the vault token create command.
vault token create
By default, this will create a child token of your current token that
inherits all the same policies.
When that parent token is revoked, children can also be revoked
all in one operation.
Authenticate with a token
vault login VAULT_TOKEN
After a token is created, you can revoke it.
vault token revoke VAULT_TOKEN
Log back in with root token.
vault login $VAULT_DEV_ROOT_TOKEN_ID
In practice, operators should not use the token create command to generate
Vault tokens for users or machines. Instead, those users or machines should
authenticate to Vault using any of Vault’s configured auth methods such as
GitHub, LDAP, AppRole, etc. For legacy applications which cannot generate their
own token, operators may need to create a token in advance. Auth methods are
discussed in more detail in the next section.
We can use GitHub Auth https://www.vaultproject.io/docs/auth/github
Authenticate via GitHub.
vault auth enable -path=github github
Just like secrets engines, auth methods default to their TYPE as
the PATH, so the following commands are equivalent.
vault auth enable github
Another example with custom path
vault auth enable -path=my-github github
Set the user’s GitHub Org
vault write auth/github/config organization=my-github-org
Map policies to a team within the organization.
vault write auth/github/map/teams/my-team value=default,my-policy
This command tells Vault to map any users who are members of the team “my-team” (in the hashicorp organization) to the policies “default” and “my-policy”.
These policies do not have to exist in the system yet - Vault will just produce a warning when you login.
As a user, you may want to find which auth methods are enabled and available.
vault auth list
To get help on Github Auth
vault auth help github
Request help information for the AWS auth method.
vault auth help aws
Request help information for the userpass auth method.
vault auth help userpass
Request help information for tokens.
vault auth help token
Create a GitHub personal access token
https://help.github.com/articles/creating-an-access-token-for-command-line-use/
Login with GitHub Auth
vault login -method=github
This new user we just created does not have many permissions in Vault.
To continue, re-authenticate with the root token.
vault login $VAULT_DEV_ROOT_TOKEN_ID
You can revoke any logins from an auth method using vault token revoke with the -mode argument. For example:
vault token revoke -mode path auth/github
Alternatively, if you want to completely disable the GitHub auth method, execute the following command.
vault auth disable github
https://learn.hashicorp.com/vault/getting-started/policies
Policies in Vault control what a user can access ie authorization.
The root and default policies are required policies and cannot be deleted.
default policy provides a common set of permissions and is included on
all tokens by default.root policy gives a token super admin permissions, similar to a root
user on a linux machine.Policies are authored in HCL https://github.com/hashicorp/hcl, but are JSON compatible.
Save to my-policy.hcl this example policy
path "secret/data/*" {
capabilities = ["create", "update"]
}
path "secret/data/foo" {
capabilities = ["read"]
}
With this policy, a user could write any secret to secret/data/, except to
secret/data/foo, where only read access is allowed.
Policies default to deny, so any access to an unspecified path is
not allowed.
Check the policy for syntax errors
vault policy fmt my-policy.hcl
Write the policy
vault policy write my-policy my-policy.hcl
An example of inline policy
vault policy write my-policy -<<EOF
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
capabilities = ["create", "update"]
}
path "secret/data/foo" {
capabilities = ["read"]
}
EOF
To see the list of policies
vault policy list
To view the contents of a specific policy
vault policy read my-policy
First, check to verify that KV v2 secrets engine has not been enabled
at secret/.
vault secrets list
If secret/ is not listed, enable it before proceeding.
vault secrets enable -path=secret/ kv-v2
To use the policy, create a token and assign it to that policy.
vault token create -policy=my-policy
Copy the generated token value and authenticate with Vault.
vault login GENERATED_TOKEN
When you access the KV v2 secrets engine
https://www.vaultproject.io/docs/secrets/kv/kv-v2/ using the vault kv CLI
commands, you can omit /data in the secret path.
Verify that you can write any data to secret/data/.
vault kv put secret/creds password="my-long-password"
Since my-policy only permits read from the secret/data/foo
path, any attempt to write fails with “permission denied” error.
This will throw a Error writing data to secret/data/foo
vault kv put secret/foo robot=beepboop
You also do not have access to sys according to the policy, so
commands like vault policy list or vault secrets list will not work.
Re-authenticate with the initial root token to continue.
vault login $VAULT_DEV_ROOT_TOKEN_ID
Use the vault path-help system with your auth method to determine
how the mapping is done since it is specific to each auth method.
For example, with GitHub, it is done per team using the
map/teams/<team> path.
vault write auth/github/map/teams/default value=my-policy
Up to this point, we have been working with the “dev” server,
which automatically authenticated us, setup in-memory storage, etc.
Learn how to configure Vault, start Vault, the seal/unseal process, and
scaling Vault.
Vault is configured using HCL https://github.com/hashicorp/hcl files.
Save in config.hcl
listener “tcp” { address = “127.0.0.1:8200” tls_disable = 1 }
:ship: Consul Getting Started Guide
<https://www.consul.io/intro/getting-started/install.html> up to the point where
you have installed Consul and started it with this command:
```bash
consul agent -dev
Start Vault using the config specified
vault server -config=config.hcl
If you get a warning message about mlock not being supported, that is
okay. However, for maximum security you should run Vault on a system that
supports mlock.
You’ll notice that you can’t execute any commands. We don’t have
any auth information! When you first setup a Vault server, you have to start by
initializing it.
Initialization is the process configuring the Vault.
When running in HA mode, this happens once per cluster, not per
server.
During initialization,
To initialize Vault use vault operator init. This is an
unauthenticated request, but it only works on brand new Vaults with no data
vault operator init
Unseal Key 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq/JgOm
Unseal Key 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiS
Unseal Key 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chA
Unseal Key 4: 0cZE0C/gEk3YHaKjIWxhyyfs8REhqkRW/CSXTnmTilv+
Unseal Key 5: fYhZOseRgzxmJCmIqUdxEm9C3jB5Q27AowER9w4FC2Ck
Initial Root Token: s.KkNJYWF5g0pomcCLEmDdOVCW
Vault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.
Vault does not store the generated master key. Without at least 3 key to
reconstruct the master 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.
This is the only time ever that all of this data is known by
Vault, and also the only time that the unseal keys should ever be so close
together.
For the purpose of this getting started guide, save all of these keys
somewhere, and continue.
In a real deployment scenario, you would never save these keys
together. Instead, you would likely use Vault’s PGP and Keybase.io support to
encrypt each of these keys with the users’ PGP keys. This prevents one single
person from having all the unseal keys.
See the documentation on using PGP, GPG, and Keybase https://www.vaultproject.io/docs/concepts/pgp-gpg-keybase.html
Every initialized Vault server starts in the sealed state.
The process of teaching Vault how to decrypt the data is known as unsealing the Vault.
Unsealing has to happen every time Vault starts.
To unseal the Vault, you must have the threshold number of unseal keys. In the output above, notice that the “key threshold” is 3.
Vault does not store any of the unseal key shards. Vault uses an
algorithm known as Shamir’s Secret Sharing
https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing to split the master key
into shards.
Begin unsealing the Vault:
vault operator unseal
Unseal Key (will be hidden):
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed true
Total Shares 5
Threshold 3
Unseal Progress 1/3 # Note the unseal progress
Unseal Nonce d3d06528-aafd-c63d-a93c-e63ddb34b2a9
Version 1.3.4
HA Enabled true
Also notice that the unseal process is stateful. You can go to another
computer, use vault operator unseal, and as long as it’s pointing to the same
server, that other computer can continue the unseal process.
Continue with vault operator unseal to complete unsealing the Vault.
To unseal the vault you must use three different unseal keys, the same key
repeated will not work.
vault operator unseal
When the value for Sealed changes to false, the Vault is
unsealed.
Finally, authenticate as the initial root token (it was included in the
output with the unseal keys)
vault login $VAULT_DEV_ROOT_TOKEN_ID
As a root user, you can reseal the Vault with vault operator
seal. A single operator is allowed to do this. This lets a single operator
lock down the Vault in an emergency without consulting other operators.
When the Vault is sealed again, it clears all of its state (including the encryption key) from memory. The Vault is secure and locked down from access.
https://learn.hashicorp.com/vault/getting-started/apis
Vault CLI is subset of API
If in dev mode, validate the initialization status
curl <http://127.0.0.1:8200/v1/sys/init>
Machines that need access to information stored in Vault will most likely access Vault via its REST API. For example, if a machine were using
AppRole https://www.vaultproject.io/docs/auth/approle.html
for authentication, the application would first authenticate to Vault which would return a Vault API token. The application would use that token for future communication with Vault.
For this guide, disable TLS and save to config.hcl
backend "file" {
path = "vault"
}
listener "tcp" {
tls_disable = 1
}
TLS is disabled here only for example purposes; it should never be disabled in production.
Start vault with new config
vault server -config=config.hcl
Start vault
curl \
--request POST \
--data '{"secret_shares": 1, "secret_threshold": 1}' \
<http://127.0.0.1:8200/v1/sys/init> | jq
The response should be JSON and looks something like this:
{
"keys": [
"ff27b63de46b77faabba1f4fa6ef44c948e4d6f2ea21f960d6aab0eb0f4e1391"
],
"keys_base64": [
"/ye2PeRrd/qruh9Ppu9EyUjk1vLqIflg1qqw6w9OE5E="
],
"root_token": "s.Ga5jyNq6kNfRMVQk2LY1j9iu"
}
Store root token.
export VAULT_TOKEN="s.Ga5jyNq6kNfRMVQk2LY1j9iu"
Do not store the root token in production
Using the unseal key (not the root token) from above, you can unseal the
Vault via the HTTP API:
curl \
--request POST \
--data '{"key": "/ye2PeRrd/qruh9Ppu9EyUjk1vLqIflg1qqw6w9OE5E="}' \
<http://127.0.0.1:8200/v1/sys/unseal> | jq
Enable AppRole auth for now
https://www.vaultproject.io/docs/auth/approle.html
vault auth enable <auth_method_type>
To see the cURL equivalent of the CLI command to enable AppRole auth
method, use the -output-curl-string flag.
vault auth enable -output-curl-string approle
Enable the AppRole auth method by invoking the Vault API.
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request POST \
--data '{"type": "approle"}' \
<http://127.0.0.1:8200/v1/sys/auth/approle>
Create an ACL policies https://www.vaultproject.io/docs/concepts/policies.html
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request PUT \
--data '{"policy":"# Dev servers have version 2 of KV secrets engine mounted by default, so will\n# need these paths to grant permissions:\npath \"secret/data/*\" {\n capabilities = [\"create\", \"update\"]\n}\n\npath \"secret/data/foo\" {\n capabilities = [\"read\"]\n}\n"}' \
<http://127.0.0.1:8200/v1/sys/policies/acl/my-policy>
Since my-policy expects secret/data path to exist, enable KV v2 secrets engine at secret/ using API.
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request POST \
--data '{ "type":"kv-v2" }' \
<http://127.0.0.1:8200/v1/sys/mounts/secret>
The following command specifies that the tokens issued under the AppRole my-role should be associated with my-policy.
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request POST \
--data '{"policies": ["my-policy"]}' \
<http://127.0.0.1:8200/v1/auth/approle/role/my-role>
The AppRole auth method expects a RoleID and a SecretID as its input.
The RoleID is similar to a username and the SecretID can be thought as the
RoleID’s password.
fetch the RoleID of the role named my-role and scan output for role_id.
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
<http://127.0.0.1:8200/v1/auth/approle/role/my-role/role-id> | jq -r ".data"
create a new SecretID under the my-role and scan for secret_id.
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request POST \
<http://127.0.0.1:8200/v1/auth/approle/role/my-role/secret-id> | jq -r ".data"
These two credentials can be supplied to the login endpoint to fetch a new Vault token.
curl --request POST \
--data '{"role_id": "ROLE_ID", "secret_id": "SECRET_ID"}' \
<http://127.0.0.1:8200/v1/auth/approle/login> | jq -r ".auth"
The response will be JSON, under the key auth:
{
"client_token": "s.p5NB4dTlsPiUU94RA5IfbzXv",
"accessor": "EQTlZwOD4yIFYWIg5YY6Xr29",
"policies": [
"default",
"my-policy"
],
"token_policies": [
"default",
"my-policy"
],
"metadata": {
"role_name": "my-role"
},
"lease_duration": 2764800,
"renewable": true,
"entity_id": "4526701d-b8fd-3c39-da93-9e17506ec894",
"token_type": "service",
"orphan": true
}
The returned client_token can be used to authenticate with
Vault.
The newly acquired token can be exported as the VAULT_TOKEN
environment variable value and used to authenticate subsequent Vault requests.
export VAULT_TOKEN="CLIENT_TOKEN"
Create a version 1 of secret named creds with a key password and its
value set to my-long-password.
curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request POST \
--data '{ "data": {"password": "my-long-password"} }' \
<http://127.0.0.1:8200/v1/secret/data/creds> | jq -r ".data"
{
"created_time": "2020-02-05T16:51:34.0887877Z",
"deletion_time": "",
"destroyed": false,
"version": 1
}
You can stop the server and unset VAULT_TOKEN variable.
unset VAULT_TOKEN
HTTP APIs https://www.vaultproject.io/api/index.html
https://learn.hashicorp.com/vault/getting-started/ui
When you start the Vault server in dev mode, Vault UI is automatically enabled and ready to use.
Start dev server
vault server -dev
Open a web browser and enter <http://127.0.0.1:8200/ui> to launch the UI.
The Vault UI is not activated by default.
To activate the UI, set the ui configuration option in the Vault
server configuration.
ui = true
listener "tcp" {
address = "10.0.1.35:8200"
}
storage "consul" {
}
The UI runs on the same port as the Vault listener. As such, you must
configure at least one listener stanza in order to access the UI.