We’ve been hearing from vendors that you want additional flexibility and control over token-based access, so we’ve spent the last several weeks digging into the user problem and exploring best practices and solutions. The result? New and improved tokens, which provide more controlled API and CLI access in the vendor portal!
What are tokens and how have they been in place to date?
Tokens are like handshakes — authorizations that allow specific users, profiles, or teams to access a given application. With Replicated today, vendors have been using tokens to access and work with the Vendor CLI and REST API commands for automated customer, channel and release management. These tokens have been made available at the team level to authenticate anyone on a vendor’s team for this access.
Since these are at the team level, this means that the tokens allow the same access to everyone on the team — read or read/write, however, the access is defined. This means that teams with different profiles of users — that is, different types of roles on the team — may have more or less access than they need to perform their job. This flies in the face of the ‘least privilege’ security principle — an approach that gives each user only as much access as they absolutely need to perform their work.
What an approach like ‘least privilege’ achieves for the environment as a whole is a much more precise security posture that can be managed and governed with greater granularity. The way this is done is by role-based access control, or RBAC. And when the Replicated team looked at how we’re doing tokens today versus how they could be done even better, well… we knew it was time to innovate.
So, What’s Better than Team Tokens?
There are two ways to achieve this more granular, customized security posture — through user tokens and through service account tokens. Let’s start with user tokens.
User Tokens
First, what are they? User tokens are personal — specific to an individual user and their job profile or role. Things like authentication, RBAC and audit logging are directly tied to the user account that generated the token. This means that access and capabilities can be aligned to exactly what this user needs to perform their role.
Next, how do user tokens work? When user tokens are used, the authenticated session is scoped to the user’s RBAC policy that created the token. In other words, the token can have read or read/write access and will only apply to the resources specified in the RBAC policy assigned to their user account in the vendor portal.
And finally here, there are also a few other things to consider with user tokens:
- The token can only be revoked by the user who created it.
- If a user’s account is removed from the team, all user tokens created by that user will be automatically revoked.
- Any actions taken by the user token will be viewable in the Audit Log.
- The token is only displayed once, so be sure to copy it into a secure location!
Ready to check it out? The brief demo below shows where and how to configure a user token for your account settings in the vendor portal:
Service Account Tokens
Again here, what are they? Service accounts are like user accounts, but for automated services like applications, scripts, or other processes. A token at this level is aimed to authenticate and authorize that service to do its work. These tokens should be used for any and all automated interactions that your team may need to have with the vendor portal.
How do service account tokens work? Service account tokens work similarly to user tokens; although shared among the team, they still have the RBAC policy applied.
Here, too, a few (similar) special things to think about with service account tokens:
- The token can be revoked by any admin user in the vendor portal.
- Any actions taken by the service account token will be viewable in the audit log with the service account token details tied to the event.
- Any user can create a service account token and assign their personal RBAC policy, such as read only or read/write, to the token. Only admin privileged users can assign any type of RBAC policy to a given service account token.
- Similar to user tokens, the token is only displayed once so be sure to copy it into a secure location!
Ready to see service account tokens in action? Follow along with this next demo showing where and how to configure a service account token for your account settings in the vendor portal:
Final Thoughts and What To Do Next
As you can see, user tokens and service account tokens provide a much more granular, secure, and robust way to interact with the vendor portal via the API or CLI.
Now that we have added a new class of more secure tokens, we intend to retire the less-secure team token. We realize that vendors are making use of team tokens today and will need time to migrate to the newer token types. As a first step, on September 24, we will remove the ability to create any new team tokens within the vendor portal. Existing team tokens will continue to function.
At a point in the future, we will formally deprecate existing uses of team tokens. This change will be communicated well in advance. Please reach out to your customer service team if you have any questions or concerns.
To take advantage of the improved security capabilities of user and service account tokens, we’re strongly encouraging vendors to replace any existing team tokens with user and service account tokens. Read more about using vendor API tokens in our vendor documentation.
Happy automating!