Service accounts

Problem

We have multiple use cases to support authentication methods where the actor is not a User. We want to support tokens that belong to a group or a project. We want all admins (group admins or project admins respectively) to be able to manage them, not just the user who created it. We also want to avoid the deletion of these tokens when an actual member is removed.

We have multiple different approaches so far, a couple of them:

• ScimToken is accepted by a few API endpoints and uses custom logic to authenticate / authorize a group level token.

• DeployToken can be used to authenticate to the API. This caused a security incident in the past because our code relies heavily on <code data-sourcepos="9:221-9:232">current_user</code> and it's very easy to miss when something else is passed in.

• Project Access Tokens are essentially PersonalAccessTokens. We automatically create a new user for each of them and add them as a member. The membership level is not configurable, they are added as maintainers. This is unnecessarily high for many use cases. The creation and deletion of lots of Users might also not be ideal.

That's a bunch of the security concerns so far, plus having all these various implementations are very confusing.

Proposal

✏️ Figma work space

🕹 Prototype 2020-09-01 | (Screens)

Introduce service accounts. Each service account would essentially be a User by introducing another value to the user_type enum or another boolean field. They would not be allowed to log in and should not count as licensed seats. They would be added as members, and admins would be able to manage them similarly to how members are managed currently (so membership level would be configurable too). Once created, admins would be able to create various tokens for these service accounts including PersonalAccessTokens, DeployTokens, ScimToken, etc.

We could migrate our tokens to be backed by service accounts and eliminate all existing logic for custom authentication / authorization.

This might also help with unifying all tokens, as the difference between tokens boils down to using scopes in many cases.

Other Considerations

1. Expiry of issued tokens - when do the tokens expire? is it configurable? is it different based on token type?

2. Rotation of tokens - currently this is a manual process that our customers have to set their devOps engineers reminders to do etc. Is there any way this can be automated? We should look into how competitors do this portion.

3. Continue to support Personal Access Tokens as they exist today

4. Existing Project Access Tokens - as this concept is rolled into Service Accounts, we need to have a migration plan for these - where will they end up in the UI?