Support pre-created Service Accounts in the Helm chart

[TBBle]

Is your feature request related to a problem?/Why is this needed

When using eksctl to build a cluster, it can auto-create Service Accounts with the desired IAMs Roles already configured.

However, the EBS-CSI Helm chart cannot use those existing roles as it tries to create its own, and Helm won't create resources over existing resources; nor should it.

/feature

Describe the solution you'd like in detail

The Helm chart's config allows disabling the creation of Service Accounts, and passing in the name of an existing Service Account for each use-case. This is very common in published Helm charts, e.g.
serviceAccount.create and serviceAccount.name in the nginx-ingress chart.

Describe alternatives you've considered

The workaround appears to be to create the cluster with eksctl, record the annotations and delete those service accounts, then install the EBS-CSI Helm chart passing the relevant annotations in as parameters.

I considered whether eksctl should be able to skip some ServiceAccounts during cluster creation, but that seems like an unusual case, since as mentioned above it seems that generally you can tell Helm charts to use an existing service account when they need one.

Additional context

This should be a relatively simple change in the chart, as we already have

serviceAccount:
  controller:
    annotations: {}
  snapshot:
    annotations: {}

in the values.yaml, so I expect it would look like

serviceAccount:
  controller:
    create: True
    name: ebs-csi-controller-sa
    annotations: {}
  snapshot:
    create: True
    name: ebs-snapshot-controller
    annotations: {}

and then changes in the templates to consume the new fields as appropriate.

[tomhuang12]

I would like this feature as well. Also, the deployment template for ebs-csi-controller needs to allow pod security context to specify fsGroup so that it can use the service account.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[TBBle]

/remove-lifecycle stale

[markussiebert]

I really would like to see this feature

[ayberk]

/good-first-issue

[k8s-ci-robot]

@ayberk:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.