securityContext capabilities.drop

[sjthespian]

I am trying to install kuberhealthy into a "hardened" Kubernetes 1.28.8 cluster, and the pods are failing to start because container "kuberhealthy" must set securityContext.capabilities.drop=["ALL"]. While I can set the rest of the required securityContext settings via. the helm chart values file, the capabilities key is missing from the securityContext set in deployment.yaml. (

kuberhealthy/deploy/helm/kuberhealthy/templates/deployment.yaml

Lines 90 to 98 in e7497d9

	securityContext:
	runAsNonRoot: {{ .Values.securityContext.runAsNonRoot }}
	runAsUser: {{ .Values.securityContext.runAsUser }}
	allowPrivilegeEscalation: {{ .Values.securityContext.allowPrivilegeEscalation }}
	readOnlyRootFilesystem: {{ .Values.securityContext.readOnlyRootFilesystem }}
	{{- if .Values.securityContext.seccompProfile }}
	seccompProfile:
	{{- toYaml .Values.securityContext.seccompProfile | nindent 12 }}
	{{- end }}

)

Have there been any thoughts to either adding the capabilities key to the securityContext, or adding the ability to have an arbitrary map of values to be added?

Thanks!

[PWM-BIA-TPA-PIE]

I too am having this issue with Kuberhealthy on a CIS hardened Kubernetes cluster. We are unable to set the capabilities because that option is unavailable in the deployment template, as you have pointed out, @sjthespian.

[sjthespian]

Here's a PR that I believe should address this: #1250

[peschmae]

Beeing able to add the securityContext to the inital pod that is spawned, only solves half the issue sadly :(

As mentioned in #1243 the pods generated by the checks (through the daemonset check, or deployment check), don't have a full security context set either and will fail on a restricted cluster as well.