Comments (5)
Are you having issues clearing that default? Although Helm's default value system is cumbersome to work with, an explicit null
does appear to clear this:
$ helm template ana kong/kong --set containerSecurityContext.runAsUser=null | grep -iA9 securitycontext | head -11
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
--
As #909 states, this doesn't have anything to do the reason mentioned in #1003
Versions of Kong prior to 2.0 and Kong Enterprise prior to 1.3 use Docker images that required setting a UID via Kubernetes in some environments
This is for compliance with Kubernetes 1.23+ default Restricted security policy (under "Running as Non-root user") to not run as root. Although docs state that nil should be allowed, the full story is more complex. The code check for this has failure cases for nil UID.
IIRC in practical testing I could not deploy into a restricted-enforced environment without adding the explicit run as user. I'm not familiar with how the username input to that verification function is derived, I expect it's looking at the container metadata and seeing the kong
user we create, whose UID is determined by the distro package, not the container image build.
from charts.
We are using the chart as subchart. Setting the runAsUser=null results in the default value 1000 being used.
from charts.
Testing confirms we do indeed hit that restriction if we remove this. To demonstrate, I created a restricted namespace and installed several configurations into it and default
(which has no policy configured):
48853 kubectl create -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/security/podsecurity-restricted.yaml
48855 helm install unrestricted-null kong/kong --set containerSecurityContext.runAsUser=null
48856 helm install restricted-default -n my-restricted-namespace kong/kong
48857 helm install restricted-null -n my-restricted-namespace kong/kong --set containerSecurityContext.runAsUser=null
48859 helm install restricted-null-asroot -n my-restricted-namespace kong/kong --set containerSecurityContext.runAsUser=null --set containerSecurityContext.runAsNonRoot=false
Removing it actually breaks even the unrestricted install. The check actually confirms whether the container complies with its runAsNonRoot
setting regardless of whether the namespace policy requires it:
11:13:05-0800 esenin $ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
httpbin 1/1 1 1 36m
unrestricted-null-kong 0/1 1 0 20m
11:13:12-0800 esenin $ kubectl describe po unrestricted-null-kong-7c464b8c6f-57kzj| grep -i root
ConfigMapName: kube-root-ca.crt
Warning Failed 19m (x12 over 21m) kubelet Error: container has runAsNonRoot and image has non-numeric user (kong), cannot verify user is non-root (pod: "unrestricted-null-kong-7c464b8c6f-57kzj_default(dabf4849-283d-4956-8bb1-60f9ad00d09a)", container: clear-stale-pid)
In the restricted namespace you'll get the same failure if you install with runAsNonRoot=true
and no UID. You'll additionally get a failure on the ReplicasSet if you toggle runAsNonRoot
off because it violates policy. Though not shown, installing with --set containerSecurityContext.runAsUser=null --set containerSecurityContext.runAsNonRoot=false
in default does work:
11:13:28-0800 esenin $ kubectl get deploy -n my-restricted-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
restricted-default-kong 1/1 1 1 20m
restricted-null-asroot-kong 0/1 0 0 17m
restricted-null-kong 0/1 1 0 20m
11:13:44-0800 esenin $ kubectl describe po -n my-restricted-namespace restricted-null-kong-65ddbd6947-tpxdq| grep -i root
ConfigMapName: kube-root-ca.crt
Warning Failed 18m (x12 over 20m) kubelet Error: container has runAsNonRoot and image has non-numeric user (kong), cannot verify user is non-root (pod: "restricted-null-kong-65ddbd6947-tpxdq_my-restricted-namespace(3dc95a4c-cd06-45f0-8269-fa25bdd2507b)", container: clear-stale-pid)
11:14:41-0800 esenin $ kubectl describe replicasets.apps -n my-restricted-namespace restricted-null-asroot-kong | grep -i forbidden | head -1
Warning FailedCreate 18m replicaset-controller Error creating: pods "restricted-null-asroot-kong-7cf76d44d7-88r8z" is forbidden: violates PodSecurity "restricted:latest": runAsNonRoot != true (containers "clear-stale-pid", "ingress-controller", "proxy" must not set securityContext.runAsNonRoot=false)
So AFAICT nulling the setting is the only option if we don't want to remove restricted compliance and further indicate that the container may run as root.
The implementation of the check suggests that there may be a way to create a container with no user that then passes the check, but I suspect that's not actually possible and is just an entirely hypothetical situation the code can handle. I've asked SIG Auth if they know otherwise, but in any case I think it's likely we'd clear the user from the container image build.
from charts.
We are using the chart as subchart. Setting the runAsUser=null results in the default value 1000 being used.
Fascinating. The subchart implementation never fails to amaze: helm/helm#12637
It looks like the Pod enforcement can indeed permit runAsNonRoot=true
without a UID if you use a numeric ID at build time, so patching one of the standard Dockerfiles and building gets you something that's compatible:
$ git diff
diff --git a/Dockerfile.deb b/Dockerfile.deb
index b367869..34f65a6 100644
--- a/Dockerfile.deb
+++ b/Dockerfile.deb
@@ -39,7 +39,7 @@ RUN set -ex; \
COPY docker-entrypoint.sh /docker-entrypoint.sh
-USER kong
+USER 1000
ENTRYPOINT ["/docker-entrypoint.sh"]
Having built that, in the unrestricted namespace:
$ helm install uuu kong/kong --set containerSecurityContext.runAsUser=null --set image.repository=tmp --set image.tag=tmp --set image.effectiveSemver=3.5.0
$ kubectl get po
NAME READY STATUS RESTARTS AGE
boo-kong-d7d68dcbb-hbvv5 2/2 Running 0 30m
httpbin-66c5b5bc6b-xnjxp 1/1 Running 0 74m
unrestricted-null-kong-5bf5b64798-mzpr2 0/2 Init:CreateContainerConfigError 0 11m
uuu-kong-57ffbc5bfb-ssx2v 2/2 Running
The controller already uses a numeric USER argument, so it doesn't need a custom image.
It looks like you should also be able to instruct OpenShift that some given range of UIDs is acceptable for a namespace (or project). Is that an option? It's probably simpler than maintaining a custom image, even if it's a simple one.
https://www.ibm.com/docs/en/cloud-paks/cp-management/2.2.x?topic=collection-adding-user-id-group-id-in-dockerfile
https://docs.openshift.com/dedicated/authentication/managing-security-context-constraints.html#security-context-constraints-pre-allocated-values_configuring-internal-oauth
https://developer.ibm.com/learningpaths/secure-context-constraints-openshift/deployment-specify-permissions
Some of that content suggests you can maybe set this permitted range at the Deployment level, but I'm not sure. If that's actually allowed, we could probably add those annotations to the chart resources.
from charts.
Thx for your efforts. For the time being we will set the runAsUser explicitly, even if it could change after recreation of the project.
from charts.
Related Issues (20)
- "kong stop" in wait-for-db command prevents init container from exiting gracefully, suggest kong quit" HOT 2
- Upgrade PostgreSQL dependency version
- Service monitor scraping both status port of ingress pod HOT 5
- Kong chart cannot be deployed with ArgoCD / Kustomize HOT 7
- request-size-limiting http2 requests are not supported without content-length header HOT 1
- no matches for kind "PodSecurityPolicy" in version "policy/v1beta1" HOT 2
- How to increase kong's timeout time HOT 1
- From OpenSource Kong to Kong Plus in Kubernetes (AKS) HOT 1
- kong ingress controller helm chart overwrite values to subcharts now working 0.12.0 HOT 2
- Unable to login to Kong Manager with DB-less Kubernetes deployment HOT 1
- How to deploy Kong successfully without enabling ingress controller or load balancer
- Kubernetes Ingress Controller upgrade issue HOT 1
- Kong manager password HOT 10
- `helm template kong kong/ingress` does not produce the same output like `helm template kong kong/ingress --validate` HOT 1
- Make it possible to verify released charts integrity
- kong/charts not running HOT 14
- Question regarding Kong 2.8 support in latest helm chart version (2.33.3) HOT 1
- Env not merged/override from .Values.env HOT 1
- ingressController.konnect.tlsClientCertSecretName: wrong naming
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from charts.