Under review

Unprivileged API tokens

Mike Wilson 10 months ago • updated by Steve Shipway 3 months ago 3

Create API keys that don't have access to passwords directly, but do have access to custom fields like password hash, public keys, etc.  This way Puppet/Ansible can query TeamPass directly to set passwords without any sort of intermediary step.

Under review

Thank you.

Can you please give more details because I don't get the interest of this?

Thanks for the reply, and thanks for all the tireless and hard work! :)

I'd like to have specific API keys that can't see raw passwords.  This way automation can retrieve account metadata without exposing credentials.  Specifically, I want to store password hash (as description right now) and have puppet clients pull it directly from Teampass for rollout without having to widely distribute an API key that has access to the entire store.

I would still want API keys that function like today as well so I can have automation interact with the password store (distributing changed passwords, etc).

Does that help at all?

I think what would help here, is if individual API tokens could be associated with a Role to restrict their access, rather than all API tokens just having the same global read/write over everything.

That way, puppet could use an API token with read-only privileges to just one part of the tree; other applications could have read/write to different sections.

Mike seems to be asking for the API privileges to be further restricted to certain fields in the item.  This would be good if we could define roles to have permissions at a field level rather than folder or item level, but it might be a bit hard to achieve, particularly with userdefined fields

+1 for the idea of different roles for different API tokens