You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It should be possible to provide an existing serviceaccount to the cluster runner
Currently, its not possible to have the chart use an existing service account, as the serviceAccount is only ever set, if you ask to have it created.
{{- if and .Values.rbac.create (eq .Values.rbac.serviceAccountName "") }}
Meaning if you have external resources managed by someone else, you first have to get them to prepare the asset, then deploy opensearch, then back to them to patch up the service account.
Describe the solution you'd like
A clear and concise description of what you want to happen.
The rbac section should probably have an "enabled" flag, that is used instead of the "create" flag on the stateful set, such that
Suppose you are not the one providing the kubernetes cluster, nor the assets (s3 bucket, iam policy etc) that the opensearch needs to use.
If the provider of those services can set up a service-account that has all the necessary rights configured to access these things, the opensearch deployment becomes a one step process.
If opensearch is undeployed, and redeployed, it will pick up those existing rights again
With the current chart-logic, the stateful set becomes a pet, since any changes made to the serviceaccount will be deleted when/if opensearch is undeployed and redeployed
Is your feature request related to a problem? Please describe.
It should be possible to provide an existing serviceaccount to the cluster runner
Currently, its not possible to have the chart use an existing service account, as the serviceAccount is only ever set, if you ask to have it created.
helm-charts/charts/opensearch/templates/statefulset.yaml
Line 89 in b5d7058
Meaning if you have external resources managed by someone else, you first have to get them to prepare the asset, then deploy opensearch, then back to them to patch up the service account.
Describe the solution you'd like
A clear and concise description of what you want to happen.
The rbac section should probably have an "enabled" flag, that is used instead of the "create" flag on the stateful set, such that
would result in the pods running under foo-bar-baz service account rights.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
None, except for Kustomize that allow for full seperation of control between external resources and opensearch
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: