Proposal: simplify Fiat service accounts setup


#1

Challenges with the current approach

At the moment creation of Fiat service accounts is quite tedious since it requires manual steps from people managing the Spinnaker instance:

  1. Manual POST to Front50:
curl -X POST \
  -H "Content-type: application/json" \
  -d '{ "name": "sekret-service-account@spinnaker-test.net", "memberOf": ["myApp-prod","myApp-qa"] }' \
  $FRONT50/serviceAccounts
  1. Fiat sync:
curl -X POST $FIAT/roles/sync

Yet they are necessary since a crucial step for securing of Spinnaker is to protect provider accounts. And once they are protected it’s impossible to use them in pipelines with automatic triggers.

This may complicate adoption of Spinnaker in organizations.

Proposal

Let’s implement one of the below:

  • allow to provide roles in “Run As” field of pipelines directly
  • for each role automatically create a Fiat provider account:
curl -X POST \
  -H "Content-type: application/json" \
  -d '{ "name": "group 1", "memberOf": ["group 1"] }' \
  $FRONT50/serviceAccounts

This approach makes sense because:

  • it doesn’t require any manual actions
  • only users that have the role will be able to set it in the UI
  • it will likely map naturally to role structure in organizations since there should be a role that can run an entire pipeline from start to finish.

What do you guys think about this proposal?


#2

My initial thought centers around “what happens if you need multiple roles for that service account?” I think it’s common to grant permissions to accounts and applications to distinct groups.

The other thing I would predict is just a proliferation of service accounts for orgs that have many many roles.

Lemme think about it a bit more, but I like the direction of simplifying SAs.


#3

That’s a good point but since it’s possible to set multiple permitted roles for provider accounts and applications, this issue can be solved for many common cases. For example if we consider the common pipeline:

Deployment to STG (step 1) -> Manual judgement (step 2) -> Deployment to PRO (step 3)

step 1 and step 3 indeed may require different permissions and most likely step 3 requires stronger ones (everyone who can deploy to PRO (group_pro) can also deploy to STG (group_stg) but not vice versa). So the provider account in step 1 will have group_pro AND group_stg as allowed roles and step 2 will have only group_pro

Since Spinnaker UI shows only those Fiat service accounts that are accessible by users, it shouldn’t be confusing for them.

I agree that the current approach is very flexible but also I think that it’s way too complicated for common use cases. Especially if we consider organizations where typically a central directory of users with assigned roles already exists (LDAP, Google Groups etc). And with the current approach we move that role management (partly) to another system (Spinnaker Fiat).

BTW, what do you think if automatic triggers had some kind of admin powers in Spinnaker so that they could access any provider account and application (similar to Jenkins)? This approach may sound bold but I don’t see any risks since if an application is properly protected (so that only trusted users can modify pipelines), there’s no risk that unauthorized users change pipeline with malicious purpose and trigger it via automatic triggers (for example CRON).


#4

To be honest these Fiat service accounts do not sound very natural to me because we have users, roles (that naturally map to entities of a central role provider) and then these artificial accounts that are basically needed to group roles. That’s quite confusing and ideally I would like to get rid of them (or hide them behind the scenes) so that users were only concerned about roles.
One possible approach would be to allow providing multiple roles in the “Run as” section of pipelines. Or make automated triggers trigger pipelines in “admin” mode with the most powerful permissions.


#5

Another idea we played around with was actually passing credentials from the trigger mechanism to the pipeline itself. So rather than having a “Run as”. the trigger job, lets say Jenkins, would see “oh Jazmin merged that PR, so spinnaker will use her Spinnaker credentials to run the pipeline”. That way there was some kind of trail from the merge through spinnaker, rather than having a hand off? it would definitely need integration with an outside auth system, but another approach to the problem.


#6

We implemented a simple sync service that creates a Fiat provider account for each role. And found that it works quite well in practice for us. We have around 200 groups.