LAB 6.6- Getting security context to work - Not sure if my solution is correct

ashdev

For Num 8 and 9, I found the userid of the nginx container to be 101. I tried changing the securitycontext in the security-review.yaml file to that of the uid, the container was still failing. I tried adding capabailities like NET_ADMIN from lab 6.1 with the uid of the container and with the security context already there but in both instances, the container was still failing. I did not know how to go forward with making the container run with the security context in place.

In the labs(lab 6.4) I just noticed that we never got the nginx container named webserver to run with a security context. We just commented out the pod security context and left a security context on the busybox container. I kept trying to figure out why the busybox ran with both pod and container security context defined even in lab 6.1. Was 3000 the original user id of the container? If not how was it able to run with a different uid specified in the security context? That's when I noticed the sleep command on the busybox container. I put a sleep command on the nginx container for lab 6.6 and its running with the original container security context of 2100 and pod context of 3000 in place. I am guessing it will go into an error of crashloopbackoff once the sleep command runs out.

Is that the solution? If not I have no other clue as to how to get this container to run because the labs in chapter 6 does not tell me how and if it is the solution, I dont understand. What was the point? What was this exercise trying to get me to understand/know? If a sleep command was the solution, why does a sleep command need to be in place for a securitycontext to work?

serewicz

Hello,

The UID change should have worked. Of course with very dynamic projects like Kubernetes and other open source projects many things could have changed such as Kubelet, Docker, Nginx or something else. Instead of a canned, demo environment, we use freshly downloaded software, which sometimes can cause issues with things not working as planned. Seeing and working with these issues is a priceless task for continued work with Kubernetes and trying to develop code that works and troubleshoot it when it does not.

As far as what the take-away should be is investigate what is causing an issue using get, describe and logs arguments. Also to work with securityContexts. From the troubleshooting you explained I think you have gained those skills.

I will look into reproducing the issue, and let you know what I find.

SebastienDionne

My security-pod is in a CrashLoopBackOff. So I disabled all lines related to security. After lot of googling.. I found that I could get the ID of nginx by entering

root@securityreview:/# id nginx
uid=101(nginx) gid=101(nginx) groups=101(nginx)

the pod won't start because is trying to write a root file ?

How can we get the securityContext working for that example ?

apiVersion: v1
kind: Pod
metadata:
  name: securityreview
spec:
  securityContext:
    runAsUser: 101
    runAsGroup: 101
    fsGroup: 101
  containers:
  - name:  webguy
    image: nginx
#    command:
#      - sleep
#      - "5000"

#     securityContext:
#      runAsUser: 3000
#       allowPrivilegeEscalation: true

SebastienDionne

it could be related to this issue on github

https://github.com/nginxinc/docker-nginx-unprivileged/issues/37

GeoffreySamper

I had the same issue couldn't get it running when the pod was running under user with id 101.
My logs had follow error:
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
/docker-entrypoint.sh: Configuration complete; ready for start up

Could be related to follow https://github.com/kubernetes/kubernetes/issues/56374

apparently there is a special nginx image for unprivileged nginx when using this image i can run nginx under a non root account mean user with 101

GeoffreySamper

if I add follow command to the docker file then it is possible to run the nginx under user 101.

# ensure nginx user can write to /var/cache/nginx
RUN chown 101:101 -R /var/cache/nginx/ && chmod +wr /var/cache/nginx 
#ensure nginx user can write to nginx.pid file
RUN chown 101:101 -R /var/run/ && chmod +wr /var/run/ 
#ensure we can use the setcap command
RUN apt-get update &&  apt-get install libcap2-bin -y
#ensure we can run setcap for access to port 80
RUN setcap CAP_NET_BIND_SERVICE=+eip /usr/sbin/nginx

the write access could be solved by a emptydir volume and mount path

lurdes2020

@serewicz said:
I will look into reproducing the issue, and let you know what I find.

Hi @serewicz, did you find the cause of this issue?

leon.kupper

I have still the same issue... I was able to find out the UID of the ngingx user but it was not working with 101.... @serewicz could you please "solve" or change that training step for further students as this is really frustrating....

ashauer

I can acknowledge the binding problem with the original Nginx image after using the correct user id. Tried some two hours now, even adding NET_BIND_SERVICE capability doesn't solve this. Updating the 6.6 Domain Review with a less time consuming task would be very appreciated... I used the unprivileged image now, too, to get this sh** working.

headkaze

Check out this answer on stack overflow