Can we run kong with non root privileges?

[smartaquarius10]

Hello,

We ran dry run of pod security admission(pod-security.kubernetes.io/enforce=restricted) on kong and received this warning

Warning: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile

Is it mandatory to keep it as is or we can run it with non root privileges. Does this impact the kong behavior.

[rainest]

Running as non-root is fine. All official images use a kong user that isn't root.

The chart has the ability to set Pod and container security contexts, but currently only does so for read-only root filesystems. In general, applying the context required for restricted to containers (it doesn't appear we need anything for Pods) is fine:

diff --git a/charts/kong/values.yaml b/charts/kong/values.yaml
index 676df7f..115c73b 100644
--- a/charts/kong/values.yaml
+++ b/charts/kong/values.yaml
@@ -948,6 +948,14 @@ securityContext: {}
 # securityContext for containers.
 containerSecurityContext:
   readOnlyRootFilesystem: true
+  allowPrivilegeEscalation: false
+  runAsUser: 1000
+  runAsNonRoot: true
+  seccompProfile:
+    type: RuntimeDefault
+  capabilities:
+    drop:
+    - ALL

Although not exhaustively tested, the default configuration comes online with these restrictions, and I don't have reason to expect other configurations would break with those restrictions.

The runAsUser: 1000 bit is necessary and a bit of a problem. Kubernetes has no means if determining if a named user is not UID 0 and requires a numeric UID. AFAIK we use the same user creation script for all distribution packages, and the lack of a UID there means the actual UID isn't guaranteed. It will vary depending on the distribution's configuration for new the starting UID for non-stock users.

There's some gateway scaffolding code that suggests we do enforce a consistent UID, but I'm not familiar enough with the gateway image build process to confirm that is definitely the case.

This security context is also applied across all our containers equally. The controller does not use UID 1000 (although it appears it sometimes did in the past? git blame isn't helping me figure out the history, but some iterations of the Dockerfile use 1000) although this does not appear to be an issue, as it doesn't interact with any files other than the single, world-executable (AFAIK) binary.

As a side note, this is not the case for our Kuma mesh by default (it requires root to do some iptables manipulation), but that can be sequestered in a dedicated iptables management deployment in a special namespace so that the sidecars do not need it in other namespaces.