Implement token management

[djenriquez]

Currently Vault-UI does not allow authorized users to manage tokens in Vault. Users still need to access Vault through the CLI to generate tokens and such. This feature request will allow users to perform all available token operations such as viewing, creating, modifying and revoking.

[msessa]

I'm also looking into this. Should we create a branch where we can collaborate on the code?

[djenriquez]

Yea, feel free to do so. Shippable will only push changes merged to master or release tags created.

[msessa]

Hi @djenriquez, @alexunwin

I've pushed some code from my implementation of the token management functionality in the token_management branch.

Implemented functionalities:

• List Accessors
• Revoke Accessor
• Lookup Accessor
• New token creation

TODO

• Roles
• Token utils (Revoke by token, Renew token, Lookup token)

Notes

There's a few things worth noting and perhaps discussing:

• The branch implements a new low-level vault API route in the node server to communicate with vault in it's native dialect from the react app. This is an attempt to demonstrate the feasibility of Serverless design #42. We can further discuss it on the issue page if needed.
• By leveraging the above method, the code makes extensive use of the /sys/capabilities-self API in order to decide whether or not a user is allowed to perform an action before actually attempting. This approach makes enabling/disabling controls in the UI a lot easier and also results in fewer Access Denied errors from vault, which keeps the audit log clean from false positives and easier to monitor.
• In order to reduce the number of API calls to the backend, the code caches user capabilities until logout. At the moment I'm using localStorage but it can probably be done in some better way, maybe with a app-wide state.

Any feedback is welcome, and thanks again for letting me join this awesome project!

[djenriquez]

Awesome @msessa-cotd! Sorry for the delay, just now seeing this. I'll take a look tonight and see try to gather some feedback.

[djenriquez]

@msessa-cotd

Great work. The new API route is definitely the direction best for this project as it removes unnecessary translations. If/when CORs are supported by Vault, we can most definitely apply #42 and reduce the level of maintenance quite a bit. Though I would think with this kind of setup, it maybe easier for our users as it would apply a more "ready out-of-the-box" implementation--users won't need to change anything on Vault. If HashiCorp allows CORs, this may be something we allow users to choose between, based on their requirements.

Otherwise beautiful implementation of the snackbar for accessibility. Is this functionality we can implement globally?

Caching-wise, I think defining an app-wide inmemory cache would be a good start, designed to extend further when we begin to support external caching with something like memcached or redis.

Please submit a PR for the branch for us to focus on the token specific feature development.

[djenriquez]

Actually, I just read that there are still some todos. Let's do that PR when its all ready.

[msessa]

Completed the token role management part.

There's still a number of uncovered endpoints (revoke by token, lookup by token, etc).
But without being able to list existing tokens in vault (which is a sensible design choice imho) having a UI around those functions is kind of pointless.

I think we can close this issue for now, the current code it's pretty functional at this point.