Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] sidecarset support inject serviceaccount #1747

Open
magicsong opened this issue Sep 14, 2024 · 2 comments
Open

[feature request] sidecarset support inject serviceaccount #1747

magicsong opened this issue Sep 14, 2024 · 2 comments

Comments

@magicsong
Copy link

magicsong commented Sep 14, 2024

Use Case:
For example, if a sidecar container needs to access Kubernetes resources such as ConfigMaps, Secrets, or interact with the API server for other reasons, it would require a ServiceAccount with appropriate permissions. Injecting the ServiceAccount directly through the SidecarSet simplifies this process and makes it more manageable.

Proposed Implementation:

Extend the SidecarSet specification to include an optional serviceAccountName field.
When applying the SidecarSet to a Pod, inject the specified ServiceAccount into the sidecar container configuration.

By the way, there is no reason to ask user's pod to inject a service account which not used by their app

@furykerry
Copy link
Member

it will be very limited in usage even if sidecarset support service account injection. consider the case that the pod already has service account configured, actually most pod will use the default servicer account. Shall we replace the service account with the one in sidecarset ?

@magicsong
Copy link
Author

it will be very limited in usage even if sidecarset support service account injection. consider the case that the pod already has service account configured, actually most pod will use the default servicer account. Shall we replace the service account with the one in sidecarset ?

The default service account is often just a default value that users are not aware of. The scenario I'm referring to is replacing this default. If the user is already using a service account, my application will provide documentation that requires updating its permissions rather than replacing the user's service account.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants