-
Notifications
You must be signed in to change notification settings - Fork 242
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
feat(helm): setting container securityContext, automountServiceAccountToken, serviceAccountName #4216
feat(helm): setting container securityContext, automountServiceAccountToken, serviceAccountName #4216
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR @lukashankeln 🙂
@lukashankeln could you also rebase from master and bump the chart version to |
…eAccountName Signed-off-by: Lukas Hankeln <[email protected]>
Signed-off-by: Lukas Hankeln <[email protected]>
Signed-off-by: Lukas Hankeln <[email protected]>
5a45772
to
fa18206
Compare
Good catch thank you.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @lukashankeln 👍
Can you take a look at this warning @lukashankeln? I missed it during the review 😅 Thanks! |
No problem, thanks for the quick fix! |
We are applying some strict rules to the pods that we deploy in our cluster.
For example we enforce setting
pod.spec.containers.securityContext.capabilities.drop[0].all
Currently we are only able to set
pod.spec.securityContext
via the helm chart.Furthermore we are restricting
automountServiceAccountToken
and do not allow the default serviceAccount to be used.Adding:
automountServiceAccountToken & serviceAccountName are beeing set to their respective defaults to not introduce a breaking change