When trying to create a namespace at path, it returns the following error.
$ vault namespace create ns1
Error creating namespace: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/sys/namespaces/ns1
Code: 404. Errors:
* 1 error occurred:
* unsupported path
Creating new secret engines and putting new kv entries are working well.
It worked with the Vault Enterprise version.
The namespace support is only available with Vault Enterprise.
It seems you are using the Vault Version, whereas creating Namespace and accessing Vault using namespace is done only when the Vault is Enterprise,
i.e Vault Enterprise, you can check here:
Vault Enterprise Installation
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.
Inside the secrets manager I have create a secrets group ("accessData") and stored an username / password as Shared Secret ("SAPcredentials") in this group.
In my mule flow I now would like to access these, but I haven't figured out how. I hoped for a method smiliar to the way parameters are handled in dataweave or global configurations, e.g.
p('accessData.SAPcredentials')
or
${accessData.SAPcredentials}
But apparently that's wrong - any suggestion how to do it right?
Anypoint Secrets Manager documentation states that only can be used for some services:
Secrets manager supports the management of TLS context for the following services:
Runtime Fabric ingress
You can store TLS artifacts in secrets manager and then configure Anypoint Runtime Fabric ingress with the secret reference.
API Manager in CloudHub
You can store the TLS artifacts in secrets manager and then configure Anypoint API Manager with the secret reference.
It doesn't look like it is possible to use it from a generic Mule application.
I am using Vault with postgres storage backend along with kv secret engine. I am uisng kubernetes auth method to get the vault token. I followed the below documentation to setup the vault with kubernetes
https://learn.hashicorp.com/tutorials/vault/kubernetes-minikube?in=vault/kubernetes
When I start the webapplication for the first time and try to retrieve the tokens it is working but when I delete the webapp deployment and try to deploy webapp again and try to retrieve the vault token again with the api
v1/auth/kubernetes/login
I get the following error
error: 400 Bad Request: [{"errors":["missing client token"]}
But the request has the jwt token of service account. Please see the below image
Due to this error Pod keeps restarting and all of a sudden after some time vault honours the request and returns the vault token.
This looks strange any reason for such behavior?
UPDATE:
This issue does not happen for consul backend
I am trying to create certificates for my domain. I followed cert-manager docs and installed cert-manager.
I am getting the following error:
cert-manager/controller/challenges "msg"="re-queuing item due to error processing" "error"="error instantiating google clouddns challenge solver: unable to construct clouddns provider: empty credentials; perhaps you meant to enable ambient credentials?"
My complete manifests are mentioned here:
https://github.com/jetstack/cert-manager/issues/3168
The error:
unable to construct < provider-name > provider empty credentials; perhaps you meant to enable ambient credentials?
Is relevant for other DNS providers as well.
If credentials are replaced by other authentication mechanism, it is recommended to specify the following flag explicitly under extraArgs:
extraArgs:
- --issuer-ambient-credentials
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