Skip to content
This repository has been archived by the owner on Feb 22, 2022. It is now read-only.

[stable/spinnaker] Support for custom ServiceAccounts for Spinnaker Pods #20885

Closed
snorlaX-sleeps opened this issue Feb 19, 2020 · 4 comments · Fixed by #21060
Closed

[stable/spinnaker] Support for custom ServiceAccounts for Spinnaker Pods #20885

snorlaX-sleeps opened this issue Feb 19, 2020 · 4 comments · Fixed by #21060
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@snorlaX-sleeps
Copy link
Contributor

snorlaX-sleeps commented Feb 19, 2020

Is your feature request related to a problem? Please describe.

TL;DR - Is it possible to update the ServiceAccount used by Spinnaker pods to be custom / modified / specific to the created Spinnaker pods, rather than the default ServiceAccount?

We wish to add IAM annotations to the ServiceAccount used by Spinnaker services, but do not want to give any pod using the default ServiceAccount the same permissions in AWS as Spinnaker

Currently a custom ServiceAccount can be used for the Halyard pod, but not the created Spinnaker pods (CloudDriver and Front50)

There is a note in the RBAC section that CloudDriver does not allow personal ServiceAccounts, but this was written 2 years ago

(more context below)

Describe the solution you'd like

  1. Set the ServiceAccount used by Spinnaker to be Spinnaker specific (like Halyard) not the namespace default
  2. Any of the following:
  • Allow the passing of custom ServiceAccounts to Spinnaker pods
  • Allow annotations to be added to the ServiceAccount used by the Spinnaker pods (this would require the ServiceAccount used by Spinnaker to not be the default account)

I am happy to do a PR for this myself - creating the issue for visibility.
I am really just not sure if the RBAC note I mentioned above is still true - I was hoping someone from Spinnaker maintainers might have some insight

Describe alternatives you've considered
We currently use kube2IAM, but we would like to migrate away from this

Additional context
AWS have released IAM Roles for ServiceAccounts (IRSA) as a replacement / alternative for solutions like kube2IAM and others (in Sept 2019)

This allows IAM roles to be attached to specific ServiceAccounts, rather than as pod annotations - as the authentication is now on the pod itself, rather than the worker node having the permissions of all the pods in the cluster, this ties in with the principle of least privilege
There is also no race conditions etc as it is a webhook triggered on pod-creation.

Many Helm charts allow the passing of custom ServiceAccount names for the pods, or extra annotations to the created ServiceAccounts, allowing the rollout of IRSA: externalDNS; ALBIngressController

In our clusters we have updated all our Helm services to use IRSA - apart from Spinnaker.

(EDIT 1 & 2: Formatting)

@stale
Copy link

stale bot commented Mar 20, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

@stale stale bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 20, 2020
@snorlaX-sleeps
Copy link
Contributor Author

Still waiting on #21060

@stale stale bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 23, 2020
@stale
Copy link

stale bot commented Apr 23, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

@stale stale bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 23, 2020
@stale
Copy link

stale bot commented May 7, 2020

This issue is being automatically closed due to inactivity.

@stale stale bot closed this as completed May 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant