Enhancement request: Allow access to token accessor from gatekeeper

[psfblair]

When Vault creates a response-wrapped authentication token, the token's accessor is made available in the returned wrap information. This lets privileged callers generate tokens for clients and revoke these tokens (and their created leases) later.

It would be nice to have an API endpoint whereby a privileged caller could supply a task ID and retrieve the token accessor for the token that was generated. This would allow revocation of the token.

[chill]

Might be better to return the wrap information directly and let callers deal with how they want to store a mapping between task ID and token accessors, rather than having to store that state within vgm

[nemosupremo]

I agree - I gave this some thought. We would either have to persist state somewhere inside vgm so that we don't lose that data on restarts, or store it in zookeeper/vault/outside. I'm not to keen on introducing state because for now without any state we get HA almost for free. Storing it in another datastore could work, while introducing some sort of ops overhead (we would have to expire/truncate the data we store) and I'd have to think about how that data is stored. For now it might be best for callers to implement their own solution.

[psfblair]

Returning the wrap information to the caller doesn't address the principal use case for revoking the token, which is that a Mesos task ID is used to retrieve a token before the designated container can access it. If the container starts up and fails, we know that someone else grabbed the token already. But we don't know who grabbed the token, or which token it was. Returning the wrapping information to the caller that successfully requested the token means returning it to the thief. Instead, we want a way to revoke that token so that the thief cannot use it.

There is already state being persisted inside VGM, since VGM keeps track of which task IDs have been issued tokens. VGM only needs to keep track of that information for the duration of the startup window of the application, but that would also be the most useful period of time during which to retain the token accessor. If my application fails to start because someone else already grabbed a token for my task ID, I want to grab the accessor right away and revoke that token.

There are no doubt other use cases for revoking the token from the dockerized application once it starts, but even then having the accessor returned to the application isn't ideal. Somehow after startup some external agent would have to harvest the accessor from the application. If we're worried that the application might become compromised and that we'll have to revoke the token, the application doesn't seem like the right place to be sending the token accessor.