I've created a token:
$ vault token lookup abac979c-d00d-4182-5654-793861dc0be9
Key Value
--- -----
accessor ee63d369-0823-4f5d-62c3-5fb877f36a36
creation_time 1529483637
creation_ttl 604800
display_name token
entity_id n/a
expire_time 2018-06-27T08:33:57.103907674Z
explicit_max_ttl 0
id abac979c-d00d-4182-5654-793861dc0be9
issue_time 2018-06-20T08:33:57.103907333Z
meta <nil>
num_uses 0
orphan false
path auth/token/create
policies [default openshift-token-manager]
renewable true
ttl 603405
As you can see it has openshift-token-manager policy. This policy looks like:
vault policy read openshift-token-manager
path "auth/approle/role/openshift/secret-id" {
capabilities = ["update"]
}
I'm using this token in order to create a secret-id:
$ vault write -f auth/approle/role/openshift-ro/secret-id
Error writing data to auth/approle/role/openshift-ro/secret-id: Error making API request.
URL: PUT https://vault.vault-sidekick.svc/v1/auth/approle/role/openshift-ro/secret-id
Code: 403. Errors:
* permission denied
Any ideas?
The role openshift-ro that you are trying to create a secret-id for doesn't match the role granted in your policy, openshift - so the permission denied error seems correct based on that.
Change your policy to grant access to the openshift-ro role.
Related
I'm running a PoC with HCP Vault.
I created an admin token. I logged in from my computer. Developed a policy with reading permission to a simple KV secret. I generated a token from the policy.
With the same token in the CLI I manage to get the secret. I try to fetch the data from the REST API but I receive 403.
Note: When I run Vault in dev mode locally both methods work
❯ vault token create -policy=my-spring-boot-app-policy
Key Value
--- -----
token hvs.XXX
token_accessor AAA
token_duration 1h
token_renewable true
token_policies ["default" "my-spring-boot-app-policy"]
identity_policies []
policies ["default" "my-spring-boot-app-policy"]
❯ vault login hvs.XXX
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 hvs.XXX
token_accessor AAA
token_duration 59m44s
token_renewable true
token_policies ["default" "my-spring-boot-app-policy"]
identity_policies []
policies ["default" "my-spring-boot-app-policy"]
❯ curl --header "X-Vault-Token: hvs.XXX" --request GET https://vault-cluster-public-vault-XXX.YYY.z1.hashicorp.cloud:8200/v1/secret/data/my-spring-boot-app | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 60 100 60 0 0 125 0 --:--:-- --:--:-- --:--:-- 127
{
"errors": [
"1 error occurred:\n\t* permission denied\n\n"
]
}
CLI
❯ vault kv get secret/my-spring-boot-app
========= Secret Path =========
secret/data/my-spring-boot-app
======= Metadata =======
Key Value
--- -----
created_time 2022-09-15T14:03:22.327127967Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 5
======= Data =======
Key Value
--- -----
hello.world Bye from Vault
mykey Vault Key
To get a response from HCP Vault you need to add the header X-Vault-Namespace with the value admin.
For example:
❯ curl --header "X-Vault-Token: hvs.XXX" --header "X-Vault-Namespace: admin" --request GET https://vault-cluster-public-vault-AAA.BBB.z1.hashicorp.cloud:8200/v1/secret/data/my-spring-boot-app | jq
I found the reference in https://cloud.spring.io/spring-cloud-vault/reference/html/#vault.config.namespaces
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" ]
}
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.