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
