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

fix: Remove cluster admin ClusterRoleBinding and ServiceAccount #24

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

didiladi
Copy link

This commit removes the ClusterRoleBinding and ServiceAccount from
the helm chart. The cluster admin access is not needed by the locust
service, since it just executes locust without any need to access any
resources within the kubernetes cluster.

fixes #23

This commit removes the `ClusterRoleBinding` and `ServiceAccount` from
the helm chart. The cluster admin access is not needed by the locust
service, since it just executes locust without any need to access any
resources within the kubernetes cluster.

fixes keptn-sandbox#23

Signed-off-by: Dieter Ladenhauf <dieter.ladenhauf@dynatrace.com>
@didiladi didiladi force-pushed the bugfix/23/remove-cluster-admin branch from b841482 to 36b74df Compare April 21, 2021 11:02
@christian-kreuzberger-dtx
Copy link
Contributor

I think the intention here was to have a helm-chart with values file etc... that looks the same across all services, such that when you install it you can re-use values.yaml files.

I agree that we don't need the service account, but I would like to loop in @agrimmer regarding this change.

@agrimmer
Copy link

agrimmer commented May 3, 2021

I like the approach of having a dedicated Service Account for each service.
As far as I know, this Service Account is also part of the template you get from helm create.

@didiladi
Copy link
Author

didiladi commented Jun 9, 2021

@agrimmer ok, I see your point. I'm not really concerned about the service account, but that it grants cluster admin access although it actually needs limited access to the kube-api. In my opinion keptn services should follow the principle of least privilege.

How about the following solution: Let's introduce a service account tailored to the specific needs of the locust service. By now, it only needs to read secrets from the kube-api-server, so the service account should only allow that. Sounds good?

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

Successfully merging this pull request may close these issues.

Helm chart of locust service includes service account for granting cluster admin access
3 participants