-
Notifications
You must be signed in to change notification settings - Fork 226
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: use safe securityContext as default #267
Conversation
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
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.
LGTM, did we port all changes from core here?
Signed-off-by: Jorge Turrado <jorge.turrado@docplanner.com>
Yes, I have added here exactly the same configuration added to core in this PR to be consistent |
{{- if .Values.securityContext.operator }} | ||
{{- toYaml .Values.securityContext.operator | nindent 8 }} | ||
{{- else }} | ||
{{- toYaml .Values.podSecurityContext | nindent 8 }} | ||
{{- toYaml .Values.securityContext | nindent 8 }} | ||
{{- end }} | ||
containers: | ||
- name: {{ .Values.operator.name }} | ||
securityContext: | ||
{{- if .Values.securityContext.operator }} | ||
{{- toYaml .Values.securityContext.operator | nindent 12 }} | ||
{{- if .Values.podSecurityContext.operator }} | ||
{{- toYaml .Values.podSecurityContext.operator | nindent 12 }} | ||
{{- else }} | ||
{{- toYaml .Values.securityContext | nindent 12 }} | ||
{{- toYaml .Values.podSecurityContext | nindent 12 }} |
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.
Hi @JorTurFer , I wonder why do you flip the logical meaning of securityContext
and podSecurityContext
Helm values?
Previously securityContext
was mapped to container.securityContext
, and podSecurityContext
was mapped to pod-level securityContext
. So the naming seemed to be correct.
Now it's flipped vice versa. Would it cause any backward compatibility issues for users that were previously passing custom securityContext
and podSecurityContext
values to KEDA Helm chart?
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.
lol, you are right!
I confused them 🤦 till now I have been thinking in podSecurityContext as containerSecurityContext...
are you willing to contribute solving this?
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.
I'd be glad to help but I don't think I can do it quickly. I still have PR for #261 on my to-do list but never have time :)
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.
Don't worry, I will do it tomorrow with the chart release :)
Nice catch!!
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.
Thank you @JorTurFer !
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.
hey @lsolovey |
Great, thank you for quick turnaround, @JorTurFer . |
Signed-off-by: Jorge Turrado jorge_turrado@hotmail.es
Provide a description of what has been changed
Checklist
Related to kedacore/keda#2933