Can't seal Vault, neither on CLI or with HTTP API, citing permission problems, using a token from userpass with a policy with permissions on sys/seal. However, by generating a root token it can seal normally.
The documentation at the official site mentions:
This endpoint seals the Vault. In HA mode, only an active node can be sealed. Standby nodes should be restarted to get the same effect. Requires a token with root policy or sudo capability on the path.
Policy
path "sys/seal"
{
capabilities = ["create", "sudo"]
}
Error message
Error sealing: Error making API request.
URL: PUT <HOST>/v1/sys/seal
Code: 403. Errors:
* 1 error occurred:
* permission denied
"update" capability was required.
path "sys/seal"
{
capabilities = ["create", "update", "sudo" ]
}
Related
I know we have an option to see what capabilities we have for a specific path for a given token
Example - using the command - vault token capabilities secret/foo
But is there a way to identify what are all the paths I can access for the given token with read or write or update like any capability.
I tried by vault token lookup to find the policy attached to my token. But I'm not able to read that policy to see what paths I have access.
vault token create -policy=read-policy -no-default-policy
Key Value
--- -----
token XXXXXXXXXXXXXXXXXXXXXXXX
token_accessor R3uPmiu30Hw8HgSbFcS3wkDJ
token_duration 768h
token_renewable true
token_policies ["read-policy"] ++++++++++++++++++++++++++++++++++++++++
identity_policies []
policies ["read-policy"]
After login using the token, if I try to read that policy
vault policy read read-policy
Error reading policy named read-policy: Error making API request.
URL: GET http://127.0.0.1:8200/v1/sys/policies/acl/read-policy
Code: 403. Errors:
* 1 error occurred:
* permission denied
So Do we have to include read capability for sys/policies/acl/read-policy in the creation of read policy hcl file?(Even i tried this but capabilities are denied in this path. seems only root can read)
or as per vault design, we cannot see what paths we have access? unless otherwise vault admin says? Or de we have any commands to get that information?
Correct me if I'm wrong
Further dig more into vault,i found the solution for this.We have to run the below command which will give us what paths we have what capabilities
vault read sys/internal/ui/resultant-acl --format=json|jq -r .data
{
"exact_paths": {
"auth/token/lookup-self": {
"capabilities": [
"read"
]
},
"sys/internal/ui/resultant-acl": {
"capabilities": [
"read"
]
},
"sys/mounts": {
"capabilities": [
"list"
]
}
},
"glob_paths": {
"sys/mounts/": {
"capabilities": [
"create",
"delete",
"list",
"read",
"sudo",
"update"
]
}
},
"root": false
}
So if we want our token users to know what path/capabilities they have then when we create policy we have to include the read capability to path sys/internal/ui/resultant-acl. Example i have created this policy for just managing secrets engine and i have included that capability, so that the user who is going to use the token which mapped to the policy can read what path/capability he or she have
cat /tmp/secrets-mgmt.hcl
path "sys/mounts/*" {
capabilities = ["create","read","update","delete","list","sudo"]
}
path "sys/mounts" {
capabilities = ["list"]
}
# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
capabilities = ["read"]
}
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
capabilities = ["read"]
}
I am trying to assign a policy to my ldap group/user so that a user can access the auth methods but it doesn't seem to be working. Here is my situation.
I have a policy name - test-ldap-group with capabilities :
path "auth/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "kv/*" {
capabilities = [ "read", "list" ]
}
Now I have assigned this policy to my ldap group : test-group. The 2nd one with "kv/* is working fine because I can see the secrets on deployed on kv engine but the 1st one where I am trying to assign the auth method it just gives me the error -
Not authorized
Ember Data Request GET /v1/identity/entity/id?list=true returned a 403 Payload (application/json) [object Object]
1 error occurred: * permission denied
Also this works - (this gives access to everything under kv/ which we don't want)
path "kv/*" {
capabilities = [ "read", "list" ]
}
BUT this doesn't work
path "kv/staging/db" {
capabilities = [ "read", "list" ]
}
What could be i am doing wrong here?
Vault Version - Vault v1.5.3
kv version - 1
The endpoint that is failing for you is this endpoint for listing identities. It may be the case that when you are calling this command, your user or VAULT_TOKEN don't have the required permissions to list entities. You can try to log into Vault as the root user or use the root VAULT_TOKEN if you are executing the commands via cURL, for example.
I'm trying to create a policy that allows for users to access a portion of the secret hierarchy based on their usernames. Rather than having a different policy for each user, I want to have one templated policy. I think this should work, but I keep getting permission denied errors. If I remove the templating and just hard-code the username in the policy path, secret retrieval works just fine, so it doesn't seem like it's any other part of the policy definition.
This is all with Vault 1.3.1, against a dev server, but the problem first came up on a non-dev server, with GCP/GCE authentication and database secrets, so it doesn't seem to be specific to any of those things, either.
Enable username/password authentication, and create a user that points to a new policy (to be defined later).
$ vault auth enable userpass
Success! Enabled userpass auth method at: userpass/
$ vault write auth/userpass/users/duvall policies=default,p2 password=duvall
Success! Data written to: auth/userpass/users/duvall
Login as this user and take a look at the token metadata.
$ vault login -method userpass username=duvall password=duvall
$ vault token lookup
Key Value
--- -----
accessor 9ga3alRqZ6E3aSCEBNFWJY1X
creation_time 1581468214
creation_ttl 768h
display_name userpass-duvall
entity_id 7513dc68-785b-d151-0efb-71315fc026dc
expire_time 2020-03-15T00:43:34.707416501Z
explicit_max_ttl 0s
id s.YZRQ3uclh2rg2H7gh3qH84P3
issue_time 2020-02-12T00:43:34.707423899Z
meta map[username:duvall]
num_uses 0
orphan true
path auth/userpass/login/duvall
policies [default p2]
renewable true
ttl 767h50m35s
type service
Create the aforementioned policy with a path templated based on the metadata key username.
$ export VAULT_TOKEN=root
$ echo 'path "secret/data/role-secrets/{{identity.entity.metadata.username}}/*" {capabilities = ["read"]}' | vault policy write p2 -
Success! Uploaded policy: p2
Create a secret that matches the path in the policy.
$ vault kv put secret/role-secrets/duvall/s1 foo=bar
Key Value
--- -----
created_time 2020-02-12T00:44:36.509412834Z
deletion_time n/a
destroyed false
version 1
As the user, reading the secret results in failure.
$ export VAULT_TOKEN=s.YZRQ3uclh2rg2H7gh3qH84P3
$ vault kv get secret/role-secrets/duvall/s1
Error making API request.
URL: GET http://127.0.0.1:8200/v1/sys/internal/ui/mounts/secret/role-secrets/duvall/s1
Code: 403. Errors:
* preflight capability check returned 403, please ensure client's policies grant access to path "secret/role-secrets/duvall/s1/"
Rewrite the policy to remove the templating.
$ export VAULT_TOKEN=root
$ echo 'path "secret/data/role-secrets/duvall/*" {capabilities = ["read"]}' | vault policy write p2 -
Success! Uploaded policy: p2
This time, reading the secret succeeds.
$ export VAULT_TOKEN=s.YZRQ3uclh2rg2H7gh3qH84P3
$ vault kv get secret/role-secrets/duvall/s1
====== Metadata ======
Key Value
--- -----
created_time 2020-02-12T00:44:36.509412834Z
deletion_time n/a
destroyed false
version 1
=== Data ===
Key Value
--- -----
foo bar
I'm not sure how relevant this is, but ... adding a metadata list capability to the policy changes the read error from a "preflight capability check" to a more normal "permission denied".
$ echo 'path "secret/metadata/*" {capabilities = ["list"]}\npath "secret/data/role-secrets/{{identity.entity.metadata.username}}/*" {capabilities = ["read"]}' | VAULT_TOKEN=root vault policy write p2 -
Success! Uploaded policy: p2
$ vault kv get secret/role-secrets/duvall/s1
Error reading secret/data/role-secrets/duvall/s1: Error making API request.
URL: GET http://127.0.0.1:8200/v1/secret/data/role-secrets/duvall/s1
Code: 403. Errors:
* 1 error occurred:
* permission denied
You are missing a point that if you want to give access of secrets/database/rdb/ then you have to give read and list capabilities for path secrets, databse, rdb.
Now if you have multiple secrets stored in secrets/ path that you don't want to share then you have to give deny for that paths.
I'm trying to perform a simple use case of creating a user and writing a kv secret using Vault v1.1.2:
First I do some initial setup after starting the server in production mode:
vault operator unseal <unseal key>
vault operator unseal <unseal key>
vault operator unseal <unseal key>
export VAULT_ROOT_TOKEN=<token>
Next, I do some setup, including creating a policy:
vault -version
vault login $VAULT_ROOT_TOKEN
vault auth enable userpass
vault secrets enable -version=2 -path=secret kv
vault policy write my-policy -<<EOF
path "secret/*" {
capabilities = ["create", "update"]
}
path "secret/foo" {
capabilities = ["read"]
}
path "secret/data/*" {
capabilities = ["create", "update"]
}
path "secret/data/foo" {
capabilities = ["read"]
}
EOF
vault token create -policy=my-policy
I then create a user:
vault write auth/userpass/users/chris \
password=password \
policies=my-policy,default
vault login -method=userpass username=chris password=password
Which returns:
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 ...
token_accessor ...
token_duration 10h
token_renewable true
token_policies ["default" "my-policy"]
identity_policies []
policies ["default" "my-policy"]
token_meta_username chris
Next, I try writing a kv secret:
vault kv put secret/foo my-value=s3cr3t
However, the error I get is:
Error writing data to secret/data/foo: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/secret/data/foo
Code: 403. Errors:
* 1 error occurred:
* permission denied
What am I missing?
Ok, it was my policy. I changed path "secret/data/foo" to the following and it works ok.
path "secret/data/foo" {
capabilities = ["create", "read", "update", "delete"]
}
I'm running Hashicorp Vault v1.1.0 locally in a docker container in developer mode. I exec into the container to use the cli, and I cannot complete a basic proof of concept with a policy and token which allow me to access only one secret.
Below is a transcript of the actions I've taken using v2 of the secrets engine. What am I doing wrong here?
/ # VAULT_TOKEN=myroot vault kv enable-versioning secret/
Success! Tuned the secrets engine at: secret/
/ # VAULT_TOKEN=myroot vault kv put secret/message value=mypassword
Key Value
--- -----
created_time 2019-04-11T20:23:25.0149145Z
deletion_time n/a
destroyed false
version 5
/ # cat p.hcl
path "secret/message" {
capabilities = ["read"]
}
/ # VAULT_TOKEN=myroot vault policy write message-readonly p.hcl
Success! Uploaded policy: message-readonly
/ # VAULT_TOKEN=myroot vault token create -policy="message-readonly"
Key Value
--- -----
token s.hZNCq7Q5plwA4XjcGAcsd5tg
token_accessor vpcxkGMbDBswfJPTGzzfY4he
token_duration 768h
token_renewable true
token_policies ["default" "message-readonly"]
identity_policies []
policies ["default" "message-readonly"]
/ # VAULT_TOKEN=s.hZNCq7Q5plwA4XjcGAcsd5tg vault kv get secret/message
Error reading secret/data/message: Error making API request.
URL: GET http://127.0.0.1:1234/v1/secret/data/message
Code: 403. Errors:
* 1 error occurred:
* permission denied
/ #
When you craft a policy for version 2 of the KV backend you need to specify the API paths, not the logical paths that "vault kv" uses. Your policy should look like this:
path "secret/data/message" {
capabilities = ["read"]
}
There's a bunch of other quirks you need to be aware of when crafting KV2 policies. See https://www.vaultproject.io/docs/secrets/kv/kv-v2.html for more information.