Closed leighwgordon closed 7 months ago
Hello @leighwgordon!
Thanks for the details and feature request.
I will implement your suggested changes to securityContext, but I don't know what default values can be set for each service. I don't know details of the Zabbix services Docker image and some scripts and processes may need to be run with some privileges.
Reference: https://github.com/zabbix/zabbix-docker
If you can help, you can perform some configuration testing and open a pull request to contribute to this helm chart. I will appreciate it.
Is your feature request related to a problem? Please describe. One of the most useful capabilities of securityContext is the ability to use
runAsUser
andrunAsGroup
to guarantee that processes are executing only as the specified UID/GID.There is a
securityContext
value set here, but for some reason it is defined once at the top level ofvalues.yaml
. Unless I'm missing something here, this doesn't make sense, because securityContext is intended to be set at the pod/container level.Since each image is independently configurable, it stands to reason that the
securityContext
should also be independently configurable to align with each component of the chart.Describe the solution you'd like
Values.securityContext
should be replaced with the following, and templates adjusted accordingly:Values.zabbixServer.securityContext
Values.zabbixServer.haNodesAutoClean.securityContext
Values.postgresql.securityContext
Values.zabbixProxy.securityContext
Values.zabbixAgent.securityContext
Values.zabbixWeb.securityContext
Values.zabbixWebService.securityContext
Describe alternatives you've considered Another option would be to extend this idea and preconfigure this chart with appropriate security contexts out of the box. This is usually done in other public charts I use (e.g. Bitnami charts, e.g. https://github.com/bitnami/charts/blob/main/bitnami/grafana/values.yaml#L401, which provide a more "secure by default" experience).
The only existing option is to try to craft a "one size fits all / lowest common denominator" security context using the existing top level
Values.securityContext
option but this would be quite limited and doesn't reflect the upstream intention that this context be set at the pod/container level, and means options likerunAsUser
andreadOnlyRootFilesystem
can't be set independently on different pods which may require different values.Additional context N/A