fix(deploy) Increase container security

[ubergesundheit]

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 Enable all kube-linter rules #753

Special notes for your reviewer:

Checklist

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

[ubergesundheit]

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

[rainest]

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]

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.

[rainest]

Alright, incompatibility is less of a concern: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap

It is still a breaking change though, since any added sidecars that are incompatible will need to specify context where they didn't previously, so we'd need to note as much in the changelog.

What issue were you seeing with Kuma, on which version, and with what install configuration? At least with https://kuma.io/docs/2.7.x/production/dp-config/cni/#installation and the KIND instructions I was able to set up Kong and our test echo server with Pod-level runAsNonRoot: true. That may well have tripped it since AFAIK https://kuma.io/docs/2.7.x/production/dp-config/transparent-proxying/ actually does require root, but I'd think it'd set the override on sidecars in that case.

However, I'd expect UID 1000 at the Pod level to break that also, since even if the container can run as root, it wouldn't be.

[ubergesundheit]

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]

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]

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]

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

[ubergesundheit]

@rainest is this still something worth merging?

[ubergesundheit]

Hello @pmalek can you take a look at this PR? Thank you :)

[pmalek]

These changes look good. Please rebase on latest main. Left 1 question.

[ubergesundheit]

Thanks, rebased to current main 👍

[ubergesundheit]

I've seen that kube-linter also failed for the kube-rbac-proxy in the gateway-operator chart. I rebased again and updated the containers securityContext.

The other test failures seem to be due to helm dependency failures. I think they should work after retrying

[pmalek]

Thanks @ubergesundheit 🙇