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.
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.
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.
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 am testing Keycloak authorization services in the admin console and I'm unable to understand why in the next example keycloak is authorizing a user (tested in the evaluate tab). this is my setup :
Created a realm test
Created a client democlient with Authorization Enabled on
Create the realm role Admin
Create the user adminuser and assign it to the Admin role
In the Authorization tab withing the client democlient:
In Settings -> Policy Enforcement Mode is set to Enforcing
Create 2 scopes: list and save
Create a resource Resource A with the 2 previous scopes
In Policies tab, create a new Role policy called Only admins where (of course) i only permit admins:
In Permissions tab, created a Scoped-based permission called permit only admins Resource A, list Scope:
And that's it. now i check in the evaluate tab this policy using the adminuser, role Admin, Resource A, Scope List:
success! everything is fine in the world!... except No.
checking again the policy with the adminuser, role Admin, Resource A, Scope save (a scope where I did not define any permission) Keycloak is again Authorizing this rule :/
i assumed that policy enforcement mode set to Enforcing will deny the access to scope save, from the documentation of keycloak:
The policy enforcement mode dictates how policies are enforced when evaluating authorization requests. 'Enforcing' means requests are denied by default even when there is no policy associated with a given resource. 'Permissive' means requests are allowed even when there is no policy associated with a given resource. 'Disabled' completely disables the evaluation of policies and allows access to any resource.
so... what i am doing wrong? how can i make that keycloak deny the access to the save scope? (obviously i can make a permission where i explicitly deny this scope. but i want that the default is deny as the documentation says)
Any ideas will be deeply appreciated.
I have found the Jira issue that reference this problem It's clearly a bug:
https://issues.redhat.com/browse/KEYCLOAK-9483
There is a patch that will come with the Keycloak version 9.0
https://issues.redhat.com/browse/KEYCLOAK-12438.
So we just need to wait for this release
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"