fix(deploy) Increase container security

ubergesundheit commented 5 months ago

Change default values to run containers with read-only file system and non-root user for both kong and postgres deployments.

What this PR does / why we need it:

Which issue this PR fixes

Fixes https://github.com/Kong/charts/issues/753

Special notes for your reviewer:

Checklist

[x] PR is based off the current tip of the main branch.
[x] Changes are documented under the "Unreleased" header in CHANGELOG.md
[x] New or modified sections of values.yaml are documented in the README.md
[x] Commits follow the Kong commit message guidelines

ubergesundheit commented 5 months ago

The reason specifying runAsNonRoot only in the containerSecurityContext is that injected kuma-init initContainers seem to need elevated privileges.

rainest commented 5 months ago

Do you know of anything that's functionally different in terms of enforcement or compliance validation if like settings are set at the Pod versus container level?

The rough justification for having defaults only in the container section is more or less what you've mentioned: we apply those context constraints to any container the chart itself manages, and any other container in the Pod is an unknown sidecar (with Kuma having a special status as a well-known sidecar that we try to accommodate by default). Pod-level settings might thus break those unknown sidecars and AFAIK there's no difference when applying the same setting at both levels. If there's something that's Pod-level only, we should consider that in isolation.

The Postgres settings should be fine, though we've normally mostly ignored it since it's kind of a legacy wart we discourage use of and plan to ultimately remove.

ubergesundheit commented 5 months ago

As you already wrote, the pods securityContext applies to all containers in the pod while the securityContext of a container only applies to the single container. There are some fields that can be only configured in the securityContext of the pod (fsGroup, fsGroupChangePolicy, supplementalGroups and sysctls) and some fields that are exclusive to the containers securityContext (allowPrivilegeEscalation, capabilities, privileged, procMount and readOnlyRootFilesystem). Fields runAsGroup, runAsNonRoot, runAsUser, seLinuxOptions, seccompProfile and windowsOptions are supported by both.

In terms of compliance, IMO it would be better to set most of the stuff in the pods securityContext. But that breaks injected containers. Not sure how much thought was put into kube-linters rules which we're trying to make happy in this PR.

ubergesundheit commented 5 months ago

What issue were you seeing with Kuma, on which version, and with what install configuration?

I was running tests locally with the versions specified in the test files. As said the injected Kuma initContainers were not happy with the runAsNonRoot setting as these were set explicitly to run with uid 0

rainest commented 5 months ago

Would the Pods come online if you manually added a runAsNonRoot: false to the kuma initContainers? I think that should work in namespaces that permit it.

Trying to do my own tests, but have been frustrated by some other issue interfering with my ability to run the transparent proxy mode locally.

ubergesundheit commented 5 months ago

Would the Pods come online if you manually added a runAsNonRoot: false to the kuma initContainers? I think that should work in namespaces that permit it.

As long as the pods securityContext does not already specify runAsNonRoot: true, it should work. But I did not test this.

ubergesundheit commented 2 months ago

@rainest sorry for letting this stall. I've rebased and ran make test.golden.update. I've also addressed your comment regarding securityContext

ubergesundheit commented 1 month ago

@rainest is this still something worth merging?

Kong / charts