hashicorp
Feature: CLI token list
Is your feature request related to a problem? Please describe.
When doing administrative work, I frequently want to look up a token or series of tokens. There are many reasons for this, such as wanting to see when they're expiring, or what policy is in use, or any number of other reasons. We do have the ability to do vault token lookup, but this requires I know the accessor ID (or token ID). But if I don't know the accessor ID, this becomes difficult. Without having to go and collect the accessor IDs from where they're being used, we do have the ability to do vault list auth/token/accessors, but this just gives us a list of accessors, with no context. We then have to iterate through that list to find the right token, which means an ad-hoc script. In addition, I can never remember what that path is, so I'm always googling it to find this comment.
Describe the solution you'd like
$ vault token list
Accessor Display Name Role TTL Policies
-------- ------------ ---- --- --------
abcd1234 foo 123h45m6s [mypolicy default]
efgh5678 bar myrole 35m56s [mypolicy2 default]
This is just an example of output. There are many fields available in the token, but these are probably some sensible defaults that don't make the output too wide. Though the command should also have a -format json option for outputting full details.
Describe alternatives you've considered Currently the alternative is to do something like:
vault list -format json auth/token/accessors | jq -r '.[]' | xargs -n 1 vault token lookup -accessor -format json | jq -r '"\(.data.accessor) \(.data.display_name) \(.data.role) \(.data.ttl) \(.data.policies)"' | column -t
But this is obviously much more difficult.
Explain any additional use-cases / Additional context
There are a few related issues, such as #965 and #1115.
#965 was closed stating it's too dangerous. But this is obviously not the case as I demonstrated an alternative above that's already possible, just unweildy.
#1115 was technically a question, and not a feature request, but it's a top result when googling the issue, and has seen a fair amount of interest from others.
Thanks for submitting this! For those others who are also interested in this, please hit the thumbs up emoji on the issue.
@vishalnayak I will work on this, and will let you know if I have any questions.
/assign @mahalrs
Hi @vishalnayak! I noticed that there has been a lot of requests for this feature, and I thought that this would be a great feature to carry out as a first-time contributor. I decided to take on this issue, and I should have a PR ready soon 😄 If you don't mind, I will be assigning myself for this issue. If you have any questions let me know!
/assign @sherman-grewal
I've marked the issue as internal, cause while we want to implement this in the future, we'd prefer to implement this internally as part of a broader effort to add pagination support to vault.
Carrying on the discussion from https://github.com/hashicorp/vault/pull/12420#issuecomment-917135576 over here.
we don't like adding an API that we know won't scale, and we're not much more keen to add a CLI command that would hammer Vault.
Pagination might help with this, but I can think of a few alternatives that could be simpler.
- A filter capability/parameter on the existing
auth/token/accessorsAPI. The API would still just return the accessors, but would only return ones that match the filter. - A limit parameter. This would default to
20or something small, and when the client gets more than this many accessors from theauth/token/accessorsapi, it would emit a truncated list plus a warning.
Both of these could probably be implemented regardless of the paging solution. Filtering is something we'd probably want either way. And a limit could easily be forward-compatible with a count-per-page.
A bit more radical solution would be to take advantage of H2 server push. If the client & server were http/2 capable, the auth/token/accessors handler could push the relevant token accessor details. I'm not sure of the state of GO client/server H2 implementations, and what the feasibility of this is, but this is the exact problem h2 push was meant to solve.
Hi! Thanks for those suggestions, I definitely agree that the alternatives you've put out would be valid things to attempt, although they come with their own complexities, in my opinion. For the filter capability, that is something we're thinking of too, but we'd need to like maintain in memory indexes for faster lookups, else with a large number of tokens searching wouldn't be possilble, so there's a fair bit of work involved there. The limit parameter also is something worth implementing, though I'm thinking more in the context of pagination, but it should pair well with filter too. H2 server push sounds really interesting, just looked into it! At a glance, I do feel we might not want to, cause the burden on all consuming clients to be able to deal with this might be too high ( if i'm understanding correctly ), but still, will keep it in mind.
It's been a couple years since there was any traffic on this issue -- is there any sense of whether it's likely to happen? (I'm particularly interested because it seems useful to have a way to check for unexpected root tokens, given that destroying them is recommended but the generate-root process doesn't generate limited-duration tokens by default, or even have a way to request them.)
