Authentication and Policies

By default, Vault uses token authentication.  One can use vault create token to create a new token that inherits the privileges of the creating user.

The token can be revoked by the admin.  An operator trying to revoke will get an error.

$ vault token create
Key                  Value
---                  -----
token                3WZeul5S8KgctuWgSsgB8mHQ
token_accessor       6Up6TqBg5g2oyVvZAoC9GN8j

# trying to revoke as a different user
$ vault token revoke 3WZeul5S8KgctuWgSsgB8mHQ
Error revoking token: Error making API request.

URL: PUT http://vault.local:8200/v1/auth/token/revoke
Code: 403. Errors:

* 1 error occurred:

* permission denied

# as admin user who created
$ vault token revoke 3WZeul5S8KgctuWgSsgB8mHQ
Success! Revoked token (if it existed)

UserPass Authentication

Vault supports many other authentication mechanisms.

Auth methods are the mechanism Vault uses to perform authentication; assigning identity and applying a set of access policies to a user or process.

One that’s easy to implement is the userpass method.  The user logging in still gets a token they can then use.

$ vault auth enable userpass
Success! Enabled userpass auth method at: userpass/

$ vault write auth/userpass/users/lord.nikon \
> password=R4zor-n-Bl4d3 \
> policies=admins
Success! Data written to: auth/userpass/users/lord.nikon

$ vault login -method=userpass \
> username=lord.nikon \
> password=R4zor-n-Bl4d3
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                  3vk72Ueofq9f6FBJMJtgliXH
token_accessor         2WAPnzZFl1MXWDwz97lwBtTE
token_duration         768h
token_renewable        true
token_policies         ["admins" "default"]
identity_policies      []
policies               ["admins" "default"]
token_meta_username    lord.nikon

Authorization: Policies

Vault uses HCL to define policies that can be attached to roles.

One could create a policy that reads from all, but only can create in a foo namespace

$ vault policy write my-readonly-policy -<<EOF
> path "secret/*" {
> 
>   capabilities = ["read"]
> 
> }
> 
> 
> 
> path "secret/data/*" {
> 
>   capabilities = ["read"]
> 
> }
> 
> 
> 
> path "secret/data/foo" {
> 
>   capabilities = ["read","create"]
> 
> }
> EOF
Success! Uploaded policy: my-readonly-policy

We can now attach the read-only policy to a token.  This token could be used, for instance, in a build process to read (but not update) secrets needed in the build/deployment pipeline

$ vault token create -policy=my-readonly-policy
Key                  Value
---                  -----
token                1eluleJQ0qw8HXWpixyNQP8Q
token_accessor       1cCui3p8Z0FIuFglOs8ELoPd
token_duration       768h
token_renewable      true
token_policies       ["default" "my-readonly-policy"]
identity_policies    []
policies             ["default" "my-readonly-policy"]

#create/update a kv first
$ vault kv put secret/build-secret "u=h4ck-the-pl4n3t"
Key              Value
---              -----
created_time     2019-01-01T18:32:11.0358738Z
deletion_time    n/a
destroyed        false
version          2

$ vault login 1eluleJQ0qw8HXWpixyNQP8Q
Success! You are now authenticated. The token information displayed below …snip… 

$ vault kv put secret/build-secret "u=tr4shing-our-r1ght5\!"
Error writing data to secret/data/build-secret: Error making API request.

URL: PUT http://vault.local:8200/v1/secret/data/build-secret
Code: 403. Errors:

* 1 error occurred:

* permission denied

We can also attach a policy to an auth method. For instance, if we enabled github.com logins, we could set them to the same read only permissions.

$ vault write auth/github/map/teams/default value=my-readonly-policy