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

[grafana] fix: don't automount default serviceAccount #3302

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

cwrau
Copy link
Contributor

@cwrau cwrau commented Sep 9, 2024

this is best-practice

@cwrau cwrau force-pushed the fix/dont-automount-default-serviceaccount branch from d3eee34 to 8f2f9d2 Compare September 9, 2024 09:37
@cwrau cwrau changed the title fix: don't automount default serviceAccount [grafana] fix: don't automount default serviceAccount Sep 9, 2024
Signed-off-by: Chris Werner Rau <cwrau@cwrau.info>
@cwrau cwrau force-pushed the fix/dont-automount-default-serviceaccount branch from 8f2f9d2 to bcb8073 Compare September 9, 2024 10:02
@jkroepke
Copy link
Collaborator

jkroepke commented Sep 9, 2024

Hi, please create a distinct property for it.

automountServiceAccountToken: {{ .Values.automountServiceAccountToken }}

automount default

The default service account should never used. Could you create a serviceAccount for imageRender the same way at it's done at grafana?

@cwrau
Copy link
Contributor Author

cwrau commented Sep 10, 2024

Hi, please create a distinct property for it.

automountServiceAccountToken: {{ .Values.automountServiceAccountToken }}

automount default

I was thinking about that, but why? If there is no serviceAccount defined, automount is not needed and default shouldn't be used. So the only situation in which automount even makes sense to be enabled is when a serviceAccount is defined. So why make it configurable just so every user has to touch this field, especially when set to true by default?

Could you create a serviceAccount for imageRender the same way at it's done at grafana?

Now that I think about it, is the imageRenderer even able to use a serviceAccount? Maybe we can remove this whole stuff completely?

@jkroepke
Copy link
Collaborator

It also best practice to not reference the default serviceAccount anywhere.
Such stupid scanners may still complain that the default serviceAccount is in used.

@cwrau
Copy link
Contributor Author

cwrau commented Sep 11, 2024

It also best practice to not reference the default serviceAccount anywhere.

Yes, that's why I don't think it's useful to have the automountServiceAccountToken to be configurable 👍

Such stupid scanners may still complain that the default serviceAccount is in used.

True, but they can't really detect the opposite, automountServiceAccountToken is true by default and the used serviceAccount is default by default, so the pod does indeed have, by default, access to the default serviceAccount 😅

@jkroepke
Copy link
Collaborator

True, but they can't really detect the opposite,

They complain if the default service account is used. I appreciate that you found that issue and I guess its an good time to introduce a dedicate for the image. It's common practice.

@cwrau
Copy link
Contributor Author

cwrau commented Sep 16, 2024

True, but they can't really detect the opposite,

They complain if the default service account is used. I appreciate that you found that issue and I guess its an good time to introduce a dedicate for the image. It's common practice.

Is the imageRenderer even able to use a serviceAccount? Why create one, if it won't be used?

@jkroepke
Copy link
Collaborator

Compliance/Security scanners doesn't follow logical rules as well.

@cwrau
Copy link
Contributor Author

cwrau commented Sep 16, 2024

Compliance/Security scanners doesn't follow logical rules as well.

Ok? What does that have to do with anything? 😅

Do you mean we should create an unused serviceAccount / add a flag to be able to set automountServiceAccountToken even though it makes no sense just because some random tools that don't have anything to do with this aren't good?

@jkroepke
Copy link
Collaborator

Yes

this doesn't make sense, but as per request by grafana#3302 (comment), it has to be done

Signed-off-by: Chris Werner Rau <cwrau@cwrau.info>
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.

2 participants