I have created users in the vault with the root policy attached to it.
vault write auth/userpass/users/testuser password=testuser policies=root
When I try to login with user testuser it failed exception is authentication failed authpass cannot create root token
There are only three ways to create root tokens due to the permissions that they have (ie everything).
More information here and the gist of it is:
vault operator init
By using another root token
vault operator generate-root
You should try this on your vault/client server:
vault token create -format=json -policy="root" | jq -r ".auth.client_token"
Do not forget about the $VAULT_TOKEN and $VAULT_ADDR environment variables, respectively.
As mentioned you can create the root token in 3 ways:-
vault operator init
By using root token (vault token create -ttl=0)(run this with root token)
vault operator generate-root (https://learn.hashicorp.com/tutorials/vault/generate-root)
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 have recently started using vault and trying to integrate with one of my application to hold secrets. I have set up the LDAP authentication for my users to access vault and create/access secrets. BUT after login successfully, at the top right there is an option of copy token renew token revoke token.
Is it right for these users to access the root token? Is there a way to disable that feature?
I just want my users to access/create secrets that's it and nothing else.
If you're logged in with LDAP, then those options don't apply to the root token, they apply to the user-login-session token. All authentication with Vault uses tokens, not just the root one. Whenever someone logs in with LDAP, they will be issued a new token - that's the token that the menu refers to.
You can see this for yourself - assuming you already have a valid root token, log in with LDAP, then select Revoke token from that menu. Now try doing something with that root token (e.g., log in to the web UI or run a CLI command). You'll see that it still works - it has not been revoked.
Currently, I am connecting to a corporate vault service where I am using a vault token and passing it through below header in my spring cloud config service where properties of all microservices are kept.
curl -X "GET" "http://localhost:8080/my-client-microservice/dev" -H "X-Config-Token: s.myvaulttoken"
where http://localhost:8080 is my spring cloud config service and s.myvaulttoken is my vault token. This is working absolutely fine.
I want to know the validity of this token. What I have read the documentation that token can be of two type: service or batch. I want to know whether this token can be used infinitely (as root tokens validity is infinite).
Since the client microservices require the vault token, I want to figure out the way to know the validity of a token. Can you guys help me to tell more about this?
I followed this link: https://learn.hashicorp.com/vault/getting-started/authentication
Every non-root token has a time-to-live (TTL) associated with it.
For example:
with a root token, the ttl is 0
vault token lookup -format json | jq .data.ttl
0
with a regular user, the ttl is non-zero
VAULT_TOKEN=$(vault token create -policy default -field token) vault token
lookup -format json | jq .data.ttl
2764799
This check is possible through the API as well.
I set up vault backed by a consul cluster. I secured it with https and am trying to use the cli on a separate machine to get and set secrets in the kv engine. I am using version 1.0.2 of both the CLI and Vault server.
I have logged in with the root token so I should have access to everything. I have also set my VAULT_ADDR appropriately.
Here is my request:
vault kv put secret/my-secret my-value=yea
Here is the response:
Error making API request.
URL: GET https://{my-vault-address}/v1/sys/internal/ui/mounts/secret/my-secret
Code: 403. Errors:
* preflight capability check returned 403, please ensure client's policies grant access to path "secret/my-secret/"
I don't understand what is happening here. I am able to set and read secrets in the kv engine no problem from the vault ui. What am I missing?
This was a result of me not reading documentation.
The request was failing because there was no secret engine mounted at that path.
You can check your secret engine paths by running vault secrets list -detailed
This showed that my kv secret engine was mapped to path kv not secret as I was trying.
Therefore running vault kv put kv/my-secret my-value=yea worked as expected.
You can enable secret engine for specific path
vault secrets enable -path=kv kv
https://www.vaultproject.io/intro/getting-started/secrets-engines
You need to update secret/my-secret to whichever path you mounted when you enable the kv secret engine.
For example, if you enable the secret engine like this:
vault secrets enable -version=2 kv-v2
You should mount to kv-v2 instead of secret
vault kv put kv-v2/my-secret my-value=yea
I'm trying to access Kubernetes Dashboard via a kubeconfig file but I don't know how to create a kubeconfig file to access it.
I can access it by a token way but I want to access it by a kubeconfig file, too.
thanks
Can you explain what you mean when you say you can access it by token but not through a kubeconfig? Kubeconfigs simply store authentication information in them, which can include authentication via a token.
Assuming the rest of your kubeconfig file is populated, you just need to modify it so that your user information contains the token, like so:
users:
- name: my-user
user:
token: <token-here>