Vault: permission denied when getting/setting secrets using token generated by app-id

Created on 24 Jun 2016  路  8Comments  路  Source: hashicorp/vault

I'm trying to write a vault loader for Confabulous but getting permission denied when getting/setting secrets using a token generated by app-id. However if I hard code a token returned from userpass everything works fine. Any idea where I'm going wrong?

With token generated by app-id

$ tcpdump -i any -A -s 1024 port 8200

POST /v1/auth/app-id/login HTTP/1.1
host: localhost:8200
accept: application/json
content-type: application/json
content-length: 47
Connection: close

{"app_id":"svc-demo-api","user_id":"demo-live"}


HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 23 Jun 2016 22:34:02 GMT
Content-Length: 399
Connection: close

{"lease_id":"","renewable":false,"lease_duration":0,"data":null,"warnings":null,"auth":{"client_token":"c302d850-9eb4-99c8-2366-da23962f95ee","accessor":"31f372f5-249b-9a88-b511-20355b99b6e0","policies":["default","demo-live"],"metadata":{"app-id":"sha1:86146399ffe1eedb571d59fbb431457b3a6d02fa","user-id":"sha1:d8cab76d2f4284ec022e1fd681bd3556c9bf5190"},"lease_duration":2592000,"renewable":true}}


POST /v1/secret/live/demo HTTP/1.1
X-Vault-Token: c302d850-9eb4-99c8-2366-da23962f95ee
host: localhost:8200
accept: application/json
content-type: application/json
content-length: 19
Connection: close

{"loaded":"loaded"}


HTTP/1.1 403 Forbidden
Content-Type: application/json
Date: Thu, 23 Jun 2016 22:34:02 GMT
Content-Length: 33
Connection: close

{"errors":["permission denied"]}

With token generated form userpass

$ vault auth -method userpass username=demo-live password=foo
==> WARNING: VAULT_TOKEN environment variable set!

  The environment variable takes precedence over the value
  set by the auth command. Either update the value of the
  environment variable or unset it to use the new token.

Successfully authenticated!
token: 2a6f3db3-7821-045d-4180-7bf695927ed8
token_duration: 0
token_policies: [root]

$ tcpdump -i any -A -s 1024 port 8200

POST /v1/secret/live/demo HTTP/1.1
X-Vault-Token: 2a6f3db3-7821-045d-4180-7bf695927ed8
host: localhost:8200
accept: application/json
content-type: application/json
content-length: 19
Connection: close

{"loaded":"loaded"}


HTTP/1.1 204 No Content
Content-Type: application/json
Date: Thu, 23 Jun 2016 22:43:21 GMT
Connection: close


GET /v1/secret/live/demo HTTP/1.1
X-Vault-Token: 2a6f3db3-7821-045d-4180-7bf695927ed8
host: localhost:8200
accept-encoding: gzip, deflate
accept: application/json
Connection: close


HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 23 Jun 2016 22:43:21 GMT
Content-Length: 114
Connection: close

{"lease_id":"","renewable":false,"lease_duration":2592000,"data":{"loaded":"loaded"},"warnings":null,"auth":null}

Most helpful comment

I am having a similar issue:
vault auth root
Error validating token: Error making API request.
URL: GET http://127.0.0.1:8200/v1/auth/token/lookup-self
Code: 403. Errors: * permission denied

While running tidy:
[root@RAC1 ~]# curl -X POST http://127.0.0.1:8200/v1/auth/token/tidy -H 'X-VAULT-TOKEN:<>'
{"errors":["permission denied"]}

How can I get execute vault auth root and get past this error.
Thanks Amer.

All 8 comments

app-id configuration

$ vault read auth/app-id/map/app-id/svc-demo-api
Key             Value
display_name    svc-demo-api
key             svc-demo-api
value           demo-live

$ vault read auth/app-id/map/user-id/demo-live
Key      Value
key      demo-live
value    svc-demo-api

userpass configuration

$ vault read auth/userpass/users/demo-live
Key         Value
policies    demo-live

Hi there,

The two logins are configured to provide different policies on the issued token. One is giving you two policies which appear to not have the desired access granted; the other is giving the root policy which allows anything anywhere at anytime (and should generally never be used).

You may want to look at https://www.vaultproject.io/docs/concepts/policies.html for a better understanding of policies and their role in controlling access to Vault features.

@jefferai thanks for the response. I appreciate the need to close issues quickly, however I've been through the documentation several times, re-entered the commands in case I made a typo etc, but am still stuck. How do you see that I have different policies associated with the logins?

The response from the app-id auth request shows that the app-id is associated with 'demo-live'

{"lease_id":"","renewable":false,"lease_duration":0,"data":null,"warnings":null,"auth":{"client_token":"c302d850-9eb4-99c8-2366-da23962f95ee","accessor":"31f372f5-249b-9a88-b511-20355b99b6e0","policies":["default","demo-live"],"metadata":{"app-id":"sha1:86146399ffe1eedb571d59fbb431457b3a6d02fa","user-id":"sha1:d8cab76d2f4284ec022e1fd681bd3556c9bf5190"},"lease_duration":2592000,"renewable":true}}

Which is the same policy as userpass

$ vault read auth/userpass/users/demo-live
Key         Value
policies    demo-live

The commands I used to associate the app-id with the demo-live policy were as follows...

vault write auth/app-id/map/app-id/svc-demo-api value=demo-live display_name=svc-demo-api
vault write auth/app-id/map/user-id/demo-live value=svc-demo-api
vault policy-write demo-live /tmp/policies/live/demo.json

@cressie176 It has nothing to do with closing issues quickly; we prefer to handle questions on the mailing list (https://groups.google.com/forum/m/#!forum/vault-tool), as this gets a lot more eyes on any particular question or idea.

It also prevents problematic issue workflows for questions where either the issue is closed immediately but then discussion continues on a closed issue; or, the issue is not closed, discussion dies down, and the issue remains open indefinitely waiting for further potential replies.

The response from the app-id request shows

"policies":["default","demo-live"]

But your output from the userpass login shows

token_policies: [root]

Perhaps you changed the policy after the first login request...?

Thanks @jefferai. Looks like when I tested with the hard coded token I mistakenly copied the root one instead. When I try with correct token returned from vault auth -method userpass I also get permission denied, so at least things are now consistent. Suspect it must be a problem with my policy. Thanks for your help and if don't get to bottom of it or have more questions I'll post them on the mailing list.

:+1:

I am having a similar issue:
vault auth root
Error validating token: Error making API request.
URL: GET http://127.0.0.1:8200/v1/auth/token/lookup-self
Code: 403. Errors: * permission denied

While running tidy:
[root@RAC1 ~]# curl -X POST http://127.0.0.1:8200/v1/auth/token/tidy -H 'X-VAULT-TOKEN:<>'
{"errors":["permission denied"]}

How can I get execute vault auth root and get past this error.
Thanks Amer.

Was this page helpful?
0 / 5 - 0 ratings