How to manage spinnaker shared by different teams


Recently we are considering to introduce spinnaker for CD. But after some investigation, I got a few questions that were merely answered.

Can anyone give me some hints on following topics?

  • We want to set up a shared spinnaker for several teams (10+), how do I secure the provider secrets (aws accounts, kubeconfigs, etc)? I think in most of the keys are mounted as kubernetes secrets, which are not so secret, is there any example to integrate secret servers to load these accounts?

  • Another problem is, besides using hal config, is there a way to add a new cloud provider (with UI or something)? Currently we consider to build a website that triggers hal config & apply on user submit. But I wonder if there is any recommended practice on this purpose.


One approach to managing provider secrets is to use the machine service account that Spinnaker is running on (e.g. on Kubernetes notes or the VM itself) and grant rights to that service account in the respective targets you want to deploy to.

As for hal config, there is no web UI at the moment. Common practices range from storing the hal config in SCM (this works if you’re using the method I describe above with credentials), or archiving the entire ~/.hal directory through any number of methods (from tarballs to puppet scripts, use your own security methods). We’ve put a little thought into this, but have found a range of conflicting operating patterns which made this less attractive to pursue in the short term.


Thanks for the suggestion, @stevenkim.

If I did not misunderstand, the spinnaker admins can access the credentials if they have access to that service account. That would still be concerning since we planned to use spinnaker for production deploy. In our case, ideally, an operator of spinnaker should not have access to any user secrets, or the secrets should be encrypted.

I think clouddriver currently reads credentials (especially kubernetes configs) from file system. Is there any approach that I can configure clouddriver to read from an secret server (with an encrypted token) or an encrypted file?


First, a clarification on my post - by machine service account, I mean the machine credential (e.g. in GCE the Compute Engine default service account), not necessarily a credential file. So while that removes the exposure of credential files which can be passed around, it still doesn’t resolve the issue you point out, which is that if someone were to shell into that machine, they have access to all Spinnaker targets granted to that machine.

Fundamentally, you are either dealing with passable tokens or environment credentials. I think what you’re asking simply is about Spinnaker support for secrets management systems (e.g. vault), as an alternative to k8s native secrets management system, for which the answer is no.

It’s certainly a useful feature, and if the community indicates it’s a priority let’s represent it accordingly.


Thanks very much for the clarification!


Integrating with Vault is definitely a useful feature. Our organization has the same secrets management issue mentioned in this thread. What can I do to prioritize this feature? Create a PR or issue in github?