IBM / portieris

A Kubernetes Admission Controller for verifying image trust.
Apache License 2.0
332 stars 78 forks source link

runAsUser incompatible with IBM Cloud Openshift. #237

Open sjhx opened 3 years ago

sjhx commented 3 years ago

What commit ID of Portieris did you experience the problem with?

https://github.com/IBM/portieris/commit/cf91952b2e00567098d3161241fcd2da156a075a 0.9.4

What went wrong?

The helm install failed reporting that the value of runAsUser should be in the range 100063000 - 100063999

What should have happened differently?

Should complete installation.

How can it be reproduced?

Obtain an IBM Cloud openshift cluster and install with `helm install portieris --namespace portieris --create-namespace ./portieris-0.9.4.tgz

Any other relevant information

works with --set securityContext.runAsUser=100063001

triceam commented 3 years ago

I'm seeing the same thing, but 100063001 doesn't work for me.

Error creating: pods "portieris-6b7cdbfb89-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 100063001: must be in the ranges: [1000650000, 1000659999]]

(Running in OpenShift on IBM Cloud)

triceam commented 3 years ago

I just reinstalled in the same cluster, and now i'm seeing a different range:

[spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 1000650001: must be in the ranges: [1000820000, 1000829999]]

molepigeon commented 3 years ago

It doesn't look like there's any intersect between the required values in the two error messages - it seems like there's no specific UID that would always work.

Instead we can either doc having to use --set securityContext.runAsUser to something within the range allowed by the SCC (sounds unpleasant), or add a new SCC that allows a known user ID: OpenShift docs. I don't know what the implications of adding a new SCC are though - I don't think we can restrict an SCC to only work for our pods so we would need to be careful what we allow. Marking help wanted in case someone with more understanding of OpenShift SCCs can lend a hand.

But for the meantime @triceam , using the --set securityContext.runAsUser with a value within the allowed range should work for your installs.

molepigeon commented 3 years ago

I just reinstalled in the same cluster, and now i'm seeing a different range

Hm - if it's different every time you try to install on the same cluster then playing a game of cat and mouse with setting runAsUser to something within the range definitely won't be pleasant.

Sounds like the way to go is adding an SCC that allows us to fix the user in the deployments.

triceam commented 3 years ago

I got around it by editing the yaml for the helm chart.

I removed this from values.yaml:

securityContext:
  runAsUser: 1000060001

Removed this fromdeployment.yaml:

      securityContext:
        runAsUser: {{ .Values.securityContext.runAsUser }}

and removed this from securitycontextconstraint.yaml:

runAsUser:
  type: MustRunAs
  uid: {{ .Values.securityContext.runAsUser }}

... and the deployment works now. I don't know if this is best practice, but it works.

zhuyijing commented 3 years ago

it works with:

oc new-project portieris
export NSUID=`oc describe namespace portieris | grep "openshift.io/sa.scc.uid-range" | awk '{print $2}' | awk -F '/' '{print $1}'` && echo $NSUID
helm install portieris --namespace portieris ./portieris --set securityContext.runAsUser=${NSUID}