Operations quick start

Start Vault in developer mode and authenticate entities, store and retrieve your first key/value secret, and test access control with policies.

Warning

Running Vault in-memory with dev mode is insecure but useful for practicing locally. Do not use dev mode in production.

For help managing a production Vault installation, refer to the Production hardening tutorial.

For a complete Vault learning experience, refer to the Vault foundations tutorials.

Before you start

You must have Vault installed locally.

Start Vault in `dev` mode

Use the -dev and -dev-root-token flags to start the Vault server in development mode:

$ vault server -dev -dev-root-token-id="dev-only-token"

The -dev-root-token-id flag for dev servers defines the initial root token. The root token allows full access to any entity that presents the token (in this case "dev-only-token").

Warning

Root tokens grant full access to all data and functionality in your Vault server. Do not share your root token. For production deployments, we recommend creating individual administrator tokens with explicit privileges.

Authenticate to Vault

Open a new terminal and export environment variables to interact with the Vault server.
```
$ export VAULT_ADDR='http://127.0.0.1:8200'
```
Log into the Vault server using the root token.
```
$ vault login dev-only-token
```
You are now authenticated to Vault with the root token.

Enable authentication plugins

Vault supports multiple authentication methods. Authentication plugins control access to Vault for humans and machine based workloads. The userpass plugin uses basic authentication with usernames and passwords.

Use vault auth enable to enable the userpass authentication method for human clients:
```
$ vault auth enable userpass
```
The userpass auth method plugin is enabled.
Use the userpass plugin to create a demo user called opsuser with the password p@ssw0rd:
```
$ vault write auth/userpass/users/opsuser \
    password=p@ssw0rd
```
Use vault auth enable to enable the approle authentication method for machines and application clients:
```
$ vault auth enable approle
```
Use the approle plugin to create a demo role called my-app-role :
```
$ vault write auth/approle/role/my-app-role \
    secret_id_ttl=10m \
    token_ttl=20m \
    token_max_ttl=30m
```
The my-app-role role has a secret ID TTL of 10 minutes, a token TTL of 20 minutes, and a token max TTL of 30 minutes.

Enable the key/value secret plugin

Vault supports multiple secrets engine plugins. You can use secret engine plugins to manage critical information like static secrets, dynamic secrets, and PKI certificates.

The key/value plugin (kv) stores and versions arbitrary secrets. Use vault secrets enable to enable the key/value plugin:

$ vault secrets enable -path shared -version 2 kv

Store a secret

Tip

The kv plugin is a core Vault plugin and has dedicated commands in the Vault CLI. Most plugins use the vault read and vault write commands.

Use the kv put command to store the demo user credentials in the kv plugin as the secrets username and password:
```
$ vault kv put \
  -mount shared \
  kv/creds \
  username=opsuser password=p@ssw0rd
```
kv put writes the keys username and password and their values to the /creds path for the key/value plugin called kv.

Write a third key to a separate path called api-keys:

$ vault kv put \
  -mount shared \
  kv/api-keys \
  square=1234

Create a policy to protect secrets

In the previous step, you wrote a password to the kv secrets engine using the root token. The use of the root token, and root policy, is not recommended for production environments.

You can use Vault policies to control and limit access to plugin data and the operations allowed on plugin data.

Create a policy file that permits read, create, update, and delete operations on the /creds path for your kv plugin:

$ vault policy write kv-access-policy - << EOF
path "shared/data/kv/creds" {
   capabilities = ["read", "create", "update", "delete"]
}
EOF

Use vault write to attach the policy to your userpass authentication plugin policy for the opsuser user:
```
$ vault write auth/userpass/users/opsuser \
    policies=kv-access-policy
```

Test the policy

Use vault login to authenticate to Vault using the opsuser user. When prompted, enter the password p@ssw0rd:
```
$ vault login -method=userpass username=opsuser
```
You are now authenticated to Vault with the opsuser and the kv-access-policy access policy instead of the root token.
Try retrieving the secrets stored on the kv/creds path:
```
$ vault kv get -mount=shared kv/creds
```
The command retrieves the secrets stored on the kv/creds path.
Try retrieving the secrets stored on the kv/api-keys path:
```
$ vault kv get -mount=shared kv/api-keys
```
The second command fails because the policy for opsuser does not grant access to the /api-keys path.

You have successfully stored and retrieved your first secret value with a user from the userpass auth method.