I am exploring Hashicorp Vault, and I am trying to create a read-only policy. This policy should only allow users to read key(s).
Below is the policy definition:
path "transit/*" {
capabilities = ["read", "list"]
}
I am trying to read key under secrets/transit (API Call: http://127.0.0.1:8200/v1/transit/keys/key1)
I am using the below CLI command to get the key (key1 in this case):
bash-5.1# vault read transit/keys/key1
However I get the below error:
Error reading transit/keys/key1: Error making API request.
URL: GET http://127.0.0.1:8200/v1/transit/keys/key1
Code: 403. Errors:
* 1 error occurred:
* permission denied
The same command works with the master token, So I guess there is nothing wrong with the command itself, but the problem is with the policy.
Interestingly, if I grant more access to the policy as below, then I can access the keys which is really confusing. I don't want to grant users create/update/delete access.
path "transit/*" {
capabilities = ["create", "update", "read", "delete", "list"]
}
Can someone point me where I am mistaken? Thanks.
Apparently, I changed the policy name and the same policy definition mentioned above started working as expected. I'm still not sure why or what was wrong with old policy name.
Related
I'm having troubles with Vault it returns permission denied 403 error, when I try to get secrets with my k8s AppRole.
I setup vault with kv version 2 engine.
Added policy for my AppRole:
Created secret under "dev/fra1/statement":
When I login with AppRole creds I have response with required policies:
When I try to execute get request with AppRole client_token I this error:
I tried different prefixes and so on (Since people on internet had problems with them).
But then was able to localize the problem, by performing that request with root token, so it went ok:
Now I'm our of ideas, I believe the only place where the problem can be is policy, what I'm doing wrong ?
Ok, so finally figured the right prefix our, it should be:
path "kv/data/dev/*" {
capabilities = ["read"]
}
Really, there is some hell with these prefixes in vault, they should describe it better in docs.
The "secret" prefix is used in v1 of Vault's KV API. v2 uses the mount name, which by default is "kv", but can be anything when you first create the mount for your KV secrets engine.
It is important to note that some tools which use Vault's API still use v1 of the KV API to access secrets, despite that your KV secrets engine may be v2. So you may need two different permissions in your policy.
I'm facing the same issue. I have a secrets engine called TestSecretsEngine and a single secret env. In my policy I add read to the path TestSecretsEngine/data/env to no avail. I'm using the node-vault npm module and it's failing at vault.approleLogin with a 403. It's got to be something with the policy because when I add a nonexistent path, I get a 404 instead.
Im new to HashiCorp Vault and im Doing the tutorials one by one by far i have cleared installing vault and setting up the server.. I even learnt to create a secret, no problems. Im facing an issue in secret engines.. When i type the command "vault secrets enable -path=kv kv" im getting an error saying "Error enabling: Error making API request.
URL: POST http://127.0.0.1:8200/v1/sys/mounts/kv
Code: 403. Errors:
permission denied"
Can anyone pls help me..
Vault denies access to its API endpoints by default. In order to use /sys/mounts/kv, you'll need to supply the X-Vault-Token header to your HTTP request, and that token must have sufficient permissions at the sys/mounts/kv path.
https://www.vaultproject.io/api-docs/system/mounts#enable-secrets-engine
I'm trying to issue a vault CLI call to list the currently enabled audit devices. I have defined a policy against sys/audit which defines "sudo" and "list" capabilities (among others). I have been issued a token with that policy applied. However when I run vault audit list, I get a "permission denied" error.
What capabilities do I need to add to my policy in order for this to work? This is being done in a bootstrap script. (The additional capabilities currently included are because I do an 'enable' if the result of 'list' turns up that auditing is disabled. I'm trying to limit the permissions of this token to just the absolute minimum required for the two operations needed in this context.)
Policy (named "aud"):
path "sys/audit/*" {
capabilities = ["list", "read", "create", "update", "sudo"]
}
Token issuance (done elsewhere, logged in with root token):
vault token create --id=my-token --policy=aud
My script (where I attempt to use the token to login and check audit device status):
vault login my-token
vault audit list
vault audit enable file <options>
Error:
Error listing audits: Error making API request.
URL: GET http://< obfuscated >:8200/v1/sys/audit
Code: 403. Errors:
* 1 error occurred:
* permission denied
The subsequent 'vault audit enable' call works, so I know the capabilities are sufficient for that. But I'm unsure what change I need to make so that vault audit list works, since I already have "sudo" along with "list" and "read" capabilities.
It turns out that a wildcard policy for path "sys/audit/*" won't match against a request to sys/audit (no suffix). So in fact two separate path declarations are necessary.
First, for the vault audit list, this policy is sufficient:
path "sys/audit" {
capabilities = ["list", "read", "sudo"]
}
... and then for vault audit enable, the broader policy against the wildcard:
path "sys/audit/*" {
capabilities = ["create", "update", "sudo"]
}
This second one could be tightened up to only match against sys/audit/file as well.
I came up with the idea to delegate to a user the right to create a policy. The policy assigned to this user would be:
path "sys/policies/acl/user-*"
{
capabilities = ["create", "read", "update", "delete", "list"]
}
Now as the user can create a policy in the path sys/policies/acl/user-*, such policy could contain any rights to any path in Vault which of course is not what I want to achieve. I would like to restrict this policy creation right to a given path. Is this in any way possible in Vault?
There are two ways to do that:
Buy Vault with sentinel support (i believe thats the enterprise version)
Create another service that will be talking to vault when it comes to creating policies and then write your own parsers to allow/deny. Its not going to be that bad as the policies hcl config language is translatable to JSON and once you have JSON you can parse the paths and figure out if its a valid policy or not.
I can't understand how secrets list works.
I have policy with path permission.
path "sys/mounts/*" {
capabilities = ["create", "read", "update", "delete", "list","sudo"]
}
I can run enable and disable flags
$ vault secrets enable -path=Test kv
Success! Enabled the kv secrets engine at: Test/
$ vault secrets disable Test
Success! Disabled the secrets engine (if it existed) at: Test/
But I can't run list or move
vault secrets list
Error listing secrets engines: Error making API request.
URL: GET http://localhost:8200/v1/sys/mounts
Code: 403. Errors:
* permission denied
vault secrets move Test Test2
Error moving secrets engine Test/ to Test2/: Error making API request.
URL: POST http://localhost/v1/sys/remount
Code: 403. Errors:
* permission denied
Its not a file system permission issue, after change admin-token to root-token everything work fine. So anyone can explain me this behavior ?
Try:
path "sys/mounts" {
capabilities = ["read"]
}
The command are performed on sys/mounts, not sys/mounts/*
Just to add. All the secret backend paths which can be allowed or disallowed for a particular token are listed on this web page https://www.vaultproject.io/api/system/index.html
When you get permission denied to any of the URL. You need to search that URL on this page. And you will get the whole information about that system backend. e.g. You can search both "sys/remount" and "sys/mounts"