Update to work with Vault 0.6 about vault-gatekeeper

[nemosupremo]

I was thinking along the lines of I'd rather support one or the other but not both. When we target 0.6, just using response wrapping would really simplify client implementations because it would be a standard API.

I'd rather not support both at this time just because that would increase the complexity of the project, especially considering we don't have proper integration tests yet. If @chill would like to tackle it, I would gladly accept a PR that dropped the old code (and dropped support for Vault 0.5), rather trying to support both. I'd imagine in 1-2 months everyone would be on the response wrapping API and I wouldn't want people to depend on that code if it'll end up neglected.

[nemosupremo]

I'm planning to close this issue once I cut a new release. I'd like to get come tests up and running (working in the travis branch) before making a new release which should be done this week.

[nemosupremo]

Yes, the client side of the request now uses Response Wrapping which was introduced in Vault 0.6.

The only change you must make is to the vault backend, which is now written to the /response path.

curl -L \
  -H "X-Vault-Token: $VAULT_TEMP_TOKEN"  \
  -X GET "https://$VAULT_ADDR/v1/cubbyhole/response" 

The format of the response has changed as well.

[bibby]

Supporting both would be awesome (at least for a while).
I just got this working with 5, lol.

On a side note, well done @ChannelMeter .

[chill]

@siddharthist I had this same question; reading through the vault docs, vault-gatekeeper-mesos will still work with vault 0.6, as the cubbyhole endpoint still exists and still functions in the way required by vault-gatekeeper-mesos, since vault 0.5.

Despite this, it would be nice to use response wrapping, as then you get the full original vault secret back, including TTL, etc. That would save vault-gatekeeper-mesos having to write those things out into the cubbyhole itself, which it currently doesn't do anyway, but would be useful.

[nemosupremo]

I was made aware of the response wrapping quite some time ago - AFAICT, response wrapping is a formal "correct" way to handle cubbyhole auth, but is still just syntax sugar. The current method should still work with Vault 0.6, and we may want to keep doing it our way to support older vault versions for the time being.

If we ever switch to response-wrapping it will include a notice that we would be dropping support for Vault <0.6

[langston-barrett]

@nemothekid Is there a reason not to have both?

[chill]

@siddharthist @nemothekid I'm happy to / would like to build a PR to allow both, if you're interested

If a bool was added to the /token request json to indicate whether the requester wanted response wrapping to be used, older clients wouldn't have to worry about upgrading because the field in the struct that the request json gets deserialised to would just remain false.

[langston-barrett]

@nemothekid We were looking at integrating vgm with Mantl.io and we're already familiar with the new response wrapping API is especially why I ask.

@chill That sounds awesome 👍

[chill]

Happy to do so

[chill]

@nemothekid How's that going? Did you identify any issues in your testing I could try and help out with?

[nemosupremo]

Version v0.5.2 now works exclusively with wrapped responses (so only version 0.6.0 of Vault and greater).

[matthewmrichter]

Nimi, I just upgraded my deployments to Vault 6.0 and VGM 0.5.2. I'm no longer getting my perm token returned for some reason.

I pass this and successfully receive a temp token still:

VAULT_TEMP_TOKEN="`curl -s -L \
    -H 'Content-Type: application/json' \
    -X POST \
    -d '{ "task_id":"'$MESOS_TASK_ID'" }' \
    "https://$VGM_ADDR/token"`"

Then I use that temp token to try and get the perm token

curl -L \
  -H "X-Vault-Token: $VAULT_TEMP_TOKEN"  \
  -X GET "https://$VAULT_ADDR/v1/cubbyhole/vault-token" 

But since the upgrade, getting Permission Denied. Does anything change on the client side in terms of the curl request?

I am still wrapping my head around response wrapping (no pun intended) so I apologize if this is a user error.

[psfblair]

The documentation in the README in the root of the project suggests that VGM doesn't use response wrapping: "[VGM will] request the creation of 2 tokens (temp and perm). The temp token, which can only be used twice, will be first used by Vault internally to write the perm token into it's own Cubbyhole at the path response. This temp token is then provided to the service which can use that token to retrieve the perm token."

Might be good to update the README accordingly?

(I'm assuming that the protected service can now use "https://$VAULT_ADDR/v1/sys/wrapping/unwrap" rather than "https://$VAULT_ADDR/v1/cubbyhole/response" to unwrap the token?)