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

[WIP] Optional support for custom default service account #6586

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

mikkeloscar
Copy link
Contributor

This introduces an injection of a custom default service account named after the resource in the format: default-<kind>-<name>. E.g. if you deploy a Deployment with the name my-app the serviceAccountName used in the pod will be default-deployment-my-app if you didn't specify a custom serviceAccountName already. This is done for the following kinds: Deployment, StatefulSet, StackSet, Crobjob.

The motivation for this is that we have pods running with default service account and reading from the Kubernetes API. This is a leftover from before RBAC was introduced and the intention is that all such use cases be replaced with a custom service account as defined here: https://cloud.docs.zalando.net/howtos/service-accounts/
The problem is that since all workloads run with default service account by default, it's hard to identify those workloads that run with default AND read from the Kubernetes api. We have metrics from the audit-events: https://teapot.docs.zalando.net/application/kubernetes/#apiserver-client-visibility but the user is always system:serviceaccounts:<namespace>:default so it's hard to identify which deployment/statefulset/pods that actually is doing it.
By introducing a custom default service account for all main resource types we effectively give each deployment/statefulset/etc. their own identity which will make it simple to identify in the metrics.

The intention is to roll it out behind a flag and only enable it per cluster where there are a need for it because default service account is reading from the apiserver. There are some clusters where the default service account is bound to RBAC permissions. In those clusters we can't enable this because we would have to also change the bindings to not drop permissions (not entirely sure if it matters in practice, but would start by just looking into those specific cases).

@mikkeloscar mikkeloscar added do-not-merge minor Minor changes, e.g. low risk config updates, changes that do not introduce a new API call. labels Nov 22, 2023
@mikkeloscar mikkeloscar force-pushed the custom-default-sa branch 2 times, most recently from 386f23f to 3a6b5fb Compare November 22, 2023 15:51
@mikkeloscar mikkeloscar force-pushed the custom-default-sa branch 2 times, most recently from b836a72 to 81a916e Compare April 3, 2024 14:33
Signed-off-by: Mikkel Oscar Lyderik Larsen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge minor Minor changes, e.g. low risk config updates, changes that do not introduce a new API call.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant