I'm trying to setup a kv2 mount called 'personal' where each user will have his own cubbyhole...that doesn't expire. Say the company has 100 employees - they have company-wide secrets in mounts such as secrets/ , secrets/general, secrets/general/dept and so on, however I'd like each of them to have read/write access to personal/user, without other users being able to read there. How can I obtain this? I figured a policy such as this would suffice:
path "personal/data/user/*" {
capabilities = ["create", "read", "delete", "update", "list", "sudo"]
}
path "personal/user/*" {
capabilities = ["create", "read", "delete", "update", "list", "sudo"]
}
path "personal/+" {
capabilities = ["list"]
}
This, however, doesn't work as i'd like. I mean, i can get the secret from cli:
master* ± vault kv get personal/user/ipam |head
====== Metadata ======
Key Value
--- -----
created_time 2019-08-27T14:01:10.156868866Z
deletion_time n/a
destroyed false
version 3
====== Data ======
Key Value
but vault-ui doesn't let me access the 'personal/' space:
master* 2 ± vault kv list personal/
Error listing personal/metadata: Error making API request.
URL: GET https://...:8200/v1/personal/metadata?list=true
Code: 403. Errors:
* 1 error occurred:
* permission denied
If i update the last path to "personal/*", user can read everyone else's paths (not secrets, but paths), which is what i'd like to avoid.
Anybody has any ideas?
Thank you.
You'll need ACL templating
The policy would look something like this
path "personal/{{identity.entity.name}}/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
Depending on your auth method (LDAP for example), you might need to change the templated path to something like identity.entity.aliases.<<mount accessor>>.name
Related
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 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 have spring config server and vault as backend. i created a token in vault with an acl policy . when i use the token in spring.cloud.config.token it doesnt respect the acl
My sping config client has this boot strap properties
spring:
application:
name: app1
cloud:
config:
uri: https://config-server-ur:port
token: token-associated-to-acl-policy
i created an acl policy by name "app1" which allows only the "app1" to be read by the token in vault.
path "secret/app1" {
capabilities = ["read", "list"]
}
./vault token create -display-name="app1" -policy="app1"
i used the token generated in my client and it doesnt work.
when i changed the acl policy to below, it works
path "secret/*" {
capabilities = ["read", "list"]
}
However, when i access the vault directly with X-Vault-token it works perfectly as expected
I found the solution, Set spring.cloud.config.server.vault.defaultKey to empty, like this in config-server bootstrap.yml
spring.profiles.active=git, vault
spring.cloud.config.server.git.uri=properties-git-repo-url
spring.cloud.config.server.git.username=user
spring.cloud.config.server.git.password=password
spring.cloud.config.server.git.searchPaths=/{application}/xyz
spring.cloud.config.server.git.force-pull=true
spring.cloud.config.server.git.timeout=10
spring.cloud.config.server.git.order=2
spring.cloud.config.server.vault.host=vault-hostname
spring.cloud.config.server.vault.port=8200
spring.cloud.config.server.vault.scheme=https
spring.cloud.config.server.vault.backend=secret
spring.cloud.config.server.vault.defaultKey=
spring.cloud.config.server.vault.profileSeparator=/
spring.cloud.config.server.vault.skipSslValidation=true
spring.cloud.config.server.vault.order=1
spring.cloud.config.server.vault.kvVersion=1
by default spring.cloud.config.server.vault.defaultKey= is set to "application".
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"]
}