RFC: Service accounts #101
Conversation
Signed-off-by: Bohan Chen <[email protected]>
Signed-off-by: Bohan Chen <[email protected]>
Signed-off-by: Bohan Chen <[email protected]>
|
|
||
| # Proposal | ||
|
|
||
| Multiple service accounts can be created at the team level and be explicitly |
There was a problem hiding this comment.
This is a similar proposal to #63, with some differences worth calling out:
- In RFC: API Auth Flow for Applications #63, token creation is decoupled from teams, whereas in this proposal, a token must be associated to a team
- In RFC: API Auth Flow for Applications #63, the token is auto-generated, whereas in this proposal, the token is user provided
- RFC: API Auth Flow for Applications #63 just proposes access to (some subset of) the read API (there's nothing inherent about that in the auth mechanism, but there's no talk about assigning actions to a token)
The main distinction for me is point 1. Allowing service accounts to bind to multiple teams would make them more similar to how users operate, and might make it easier to automate the "full stack" - if you need to configure things per-team, you can have a single admin service account, rather than needing to manage one per team. It complicates the permissions model, though - if there's a CreateServiceAccount action, and a service account is granted that action, then that service account could escalate their permissions by creating a new service account with all actions to all teams if we aren't careful.
There was a problem hiding this comment.
Also worth pointing out #98 which takes an alternative approach (cc @efejjota)
There was a problem hiding this comment.
Allowing service accounts to bind to multiple teams would make them more similar to how users operate
If you're talking about having to explicitly configure per team, then users also have to be explicitly bound to each team. If you're talking about being able to seamlessly auth to different teams, then I think they would be able to have a similar experience by using the same token (i.e. using the same secret path) for multiple teams. Although that could be a security no-no.
if you need to configure things per-team, you can have a single admin service account, rather than needing to manage one per team.
A service account configured under the main team should have this power.
There was a problem hiding this comment.
I wonder if there's scenarios where there's non-main teams managing other teams. My current experience with multi-tenancy is that there's a cluster operator team with god mode managing the main team, and then sub teams are only 1 level deep.
main
├── team-1
└── team-2
I wonder if there's cases where there's sub-teams in charge of sub-teams
main
├── operator-1
│ ├── operator-2
│ │ └── ...
│ ├── team-2
│ └── team-3
└── team-1
| ... | ||
| service_accounts: | ||
| - name: team-onboarding | ||
| token: user-provided |
There was a problem hiding this comment.
Not sure how I feel about encoding this info in the config file, or even using a user-provided token in the first place.
Did you consider having fly generate a secure token for you to avoid the risks of using an insecure token and/or accidentally checking the token in to VCS?
EDIT: ah, I see the line below:
Concourse should not be responsible for generating or rotating this token.
Could you elaborate on the motivation for not wanting Concourse to generate the token?
There was a problem hiding this comment.
Could you elaborate on the motivation for not wanting Concourse to generate the token?
Concourse shouldn't be the source of truth for creds, that should be left to dedicated solutions like Vault. Since different clusters would have different security requirements (most importantly rotating creds), it would be nice to offload this responsibility to somewhere else.
Also, if Concourse generated (and rotated) the token, there would be additional complexities in syncing the token back into the cred manager. Whereas if the source of truth is the cred manager, we can leverage the existing creds flow.
Not sure how I feel about encoding this info in the config file, or even using a user-provided token in the first place.
I originally thought fly set-team supported ((var)) interpolation, in which case task params can be used to pass in the token from the cred manager. But I just checked and fly set-team doesn't actually support interpolation, maybe that feature should be included in this RFC?
Rendered