permissions required for lease renewal

470 views
Skip to first unread message

Steve Dillon

unread,
Jun 5, 2017, 12:46:53 PM6/5/17
to Vault
About a month ago we upgraded from vault 5.3 to 7.0.  I'm now having issues with lease renewals, maybe something changed, maybe you fixed a bug.  I'm having a heck of a time figuring out what authorizations are needed for a non-privileged user to renew a lease.

I used to use a block like this to allow users to renew their aws creds:
# Allow them to extend the life of a granted token
path "sys/renew/awsnonprod/creds/qm_xfer_svc/*" {
   capabilities = [ "update" ]
}
EOH

For testing I've even loosened that up to:
$ vault policies app_qmattach_dev
# Allow them to create AWS access keys in the non-prod account
path "awsnonprod/creds/qm_xfer_svc" {
   capabilities = [ "read" ]
}
# Allow them to extend the life of a granted token
path "sys/renew/*" {
   capabilities = [ "create","read","update","delete","list" ]
}


However when logged in as the target user, I am unable to renew my AWS access key lease:
(python3.6) steved@steve-mint ~/.dii/creds/prod1 $ vault auth -method=ldap username=sd0071 mount=ourdomain
Password (will be hidden): 
Successfully authenticated! You are now logged in.
The token below is already saved in the session. You do not
need to "vault auth" again with the token.
token: 90bdf8da-xxxx-yyyy-zzzz-89101fb7ed56
token_duration: 2764799
token_policies: [adm_terraformer app_hermes_dev app_qmattach_dev app_qmattach_lambda_dev default demo_human_policy ent_cadet_developers]
(python3.6) steved@steve-mint ~/.dii/creds/prod1 $ vault read awsnonprod/creds/qm_xfer_svc
Key             Value
---             -----
lease_id       awsnonprod/creds/qm_xfer_svc/e6be9f1f-c957-d976-7595-5fc7d6fb18bb
lease_duration 24h0m0s
lease_renewable true
access_key     AKIAIK6Y....JWA
secret_key     REMOVED
security_token <nil>

(python3.6) steved@steve-mint ~/.dii/creds/prod1 $ vault renew awsnonprod/creds/qm_xfer_svc/e6be9f1f-c957-d976-7595-5fc7d6fb18bb
Renew error: Error making API request.

Code: 403. Errors:

* permission denied

I don't know if I'm doing something wrong or we've got something wonky going on.  Any help appreciated.



Steve Dillon

unread,
Jun 5, 2017, 3:52:23 PM6/5/17
to Vault
My debugging indicates this is a bug in Vault 0.7.0 client (probably fixed in 0.7.1).  The /sys/renew endpoint expects the lease ID to be part of the URL, see sys-renew.html.md on 0.7.0 source.  However the CLI interface is posting it as part of the body instead of on URL.   From sys_lease.go, see difference between "Renew" and "Revoke", Revoke adds it to URL, Renew sends it in the body.


func (c *Sys) Renew(id string, increment int) (*Secret, error) {
r := c.c.NewRequest("PUT", "/v1/sys/renew")

body := map[string]interface{}{
"increment": increment,
"lease_id":  id,
}
if err := r.SetJSONBody(body); err != nil {
return nil, err
}

Further testing shows that permissions are correct in that I can cURL and "Vault Write" the path without the error, only the vault client shows permission denied.
$ vault read awsnonprod/creds/qm_xfer_svc
Key             Value
---             -----
lease_id       awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3
lease_duration 24h0m0s
lease_renewable true
access_key     AKIAI
secret_key     REMOVED
security_token <nil>

$ vault renew awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3
Renew error: Error making API request.

Code: 403. Errors:

* permission denied

$ curl -L  -k -X PUT --header "X-Vault-Token: 90bdf8da-6fe2-9a1e-163d-89101fb7ed56"  https://xxx.com:8200/v1/sys/renew/awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3
{"request_id":"81cc9f8d-34ac-c4b4-8896-b89735764612","lease_id":"awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3","renewable":true,"lease_duration":86400,"data":null,"wrap_info":null,"warnings":null,"auth":null}

$vault write -f sys/renew/awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3
Key             Value
---             -----
lease_id       awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3
lease_duration 24h0m0s
lease_renewable true
$ vault write  sys/renew/awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3 increment=10
Key             Value
---             -----
lease_id       awsnonprod/creds/qm_xfer_svc/a2fa5de6-5d32-96d3-d9ed-2d44690818d3
lease_duration 10s
lease_renewable true

At this point this probably is all moot, in 7.1 you moved the lease_id out of the URL and into the payload to match the client. Maybe a merge issue with 7.0 release.  I have a work-around for 0.7.0 which is to just do the vault write.  

Thanks,
Steve Dillon

Jeff Mitchell

unread,
Jun 5, 2017, 4:06:07 PM6/5/17
to Vault
Hi Steve,

There isn't really enough information to diagnose what you were seeing, but based on your description my guess is that you were using a different version of the Vault CLI client than the server and something changed.

Best,
Jeff


This email message, and any documents which may accompany it, contain information which is intended for use only by the intended recipient(s), and may contain information that is privileged and/or confidential. If you are not the intended recipient of this message you are hereby notified that any review, disclosure, dissemination, distribution, copy or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender by reply email, delete the email from your computer and destroy all copies of the communication and any attachments.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/debbdffb-0d03-49e9-91b8-3c2f7aedac5b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dillon, Steve

unread,
Jun 5, 2017, 5:39:31 PM6/5/17
to vault...@googlegroups.com
All of my vaults are at 0.7.0, The URL param vs Body param turns out not to make a difference.  The parameter moved but it's not the issue.

In prior versions I used this for permissions:

# Allow them to extend the life of a granted token
path "sys/renew/awsnonprod/creds/qm_xfer_svc/*" {
   capabilities = [ "update" ]
}
EOH

I shortened this to "sys/renew/*" to try to debug this morning.  Turns out you need to shorten to "sys/renew*" as when the URL parameter moves to the body their is no trailing slash on the URL.

cURL shows the API works with the lease_id in the URL or the body (once you get the correct permissions).

Hmm..
6 hours lost due to an errant /.

Anyway thanks for the help.




Jeff Mitchell

unread,
Jun 7, 2017, 10:33:05 AM6/7/17
to Vault
Hi Steve,

FYI, that permission is part of the 'default' policy:

# Allow a token to renew a lease via lease_id in the request body
path "sys/renew" {
    capabilities = ["update"]
}

I guess you were prevent the default policy from being added to these clients, or perhaps you cleared it out. But it's a good idea to periodically check the current state of the default policy to see our recommended setup for all tokens.

Best,
Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages