Protecting provider accounts used to deploy Spinnaker itself [solved]

#1

In Spinnaker it’s possible to restrict access to accounts so that only selected users can manage them. That way we can ensure that random people cannot for example deploy/remove pods.

But what’s the correct way to protect the account that is used to deploy Spinnaker itself (AKA the primary account)? That’s also necessary because we don’t want to have random people messing with Spinnaker pods.

If we just restrict the account to a certain group then we need to instruct halyard somehow to “provide” some valid “Run as User” value for those built-in pipelines.

So how can we protect the primary account?

#2

Halyard spins up it’s own headless, mini version of Spinnaker (called the ‘bootstrap’ instance) in order to deploy the main one. Adding restrictions to the main Spinnaker instance will not affect the bootstrap instance’s ability to make changes. But you’re right that adding restrictions to the spinnaker application (“spin”) is probably a good idea to keep other end-users from maliciously or inadvertently touching the Spinnaker services.

cc: @lwander to keep me honest.

#3

Agreed – you can also use the --bootstrap-only flag to ensure that the account used to deploy Spinnaker (has access to the Spinnaker cluster) can’t be reached using your Spinnaker.

#4

Brilliant! Thank you @lwander and @ttomsu!