Practicing skills point 33 review6.yaml

I'm still a bit confused about the answer given above, do they really mean just changing runAsUser to root id=0), that easy.
Question 33 and 34:
33. After finding the errors, log into the container and find the proper id of the nginx use.
34. Edit the pod such that the securityContext is in place and allows the web server to read the proper configuration files.

Why do they say "find the proper id of the nginx use"? Once I get container running by using root, I see that id of nginx is 101

Using runAsUser 101 to start pod/container fails with:
2021/01/16 23:41:41 [warn] 1#1: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2021/01/16 23:41:41 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

I just want to be sure I understand correctly.
I hope somebody can clarify this for me.

Regards,

To be honest I struggled with this question as well. The simplest way is just removing the whole securityContext sections but I thought this solution is to simple ...
So I ended up with:
$ cat review6.yaml
apiVersion: v1
kind: Pod
metadata:
name: securityreview
spec:
securityContext:
runAsUser: 2100
containers:
- name: webguy
image: nginx
securityContext:
runAsUser: 0
allowPrivilegeEscalation: false

but it is basically the same as removing all securityContext. So I guess the task is a little bit misleading. Would be interested to hear other opinions as well!

I eventually moved on from this domain review, didn't even bother trying to finish it, the whole thing is so badly worded/explained, no context given on what they want us to achieve. Will go find another resource to learn about Security.

Chatting to other members of my organization doing this course, they also just skipped this calling it "a mess".

I found a solution to this that I believe sticks to the spirit of the task (namely, running as the nginx user), but also might be a bit strange. I won't spell it out, but definitely spoilers ahead.

Both runAsUser clauses can be 101. The problem is the basic permissions issue the nginx service has, as it tries to create a cache directory (in a dir owned by root), and later to write a .pid file (in a dir owned by root). I solved these by making the containing dirs mounted to emptyDir volumes. Is that odd, or totally what the examiners would be looking for?

Am I correct to assume that to configure this properly, you will have to do changes in the application? And changing the "runAsUser" to root is just a workaround to get it running?

@pawelzajac @kingphil got it working, thanks!
I though the nginx config had to be change to use another port than 80, but that wasn't necessary.

This yaml works:

apiVersion: v1
kind: Pod
metadata:
  name: securityreview
spec:
  #  securityContext:
  #  runAsUser: 2100
  containers:
  - name:  webguy
    image: nginx
    securityContext:
      #runAsUser: 3000
      allowPrivilegeEscalation: false

But I have no clue, if this is a valid answer.

This is a bit tricky, look at the startup logs, we can found that the user does not have permission to write to /var/cache/nginx/ and /var/run

Not sure if this fix is valid to the exam

apiVersion: v1
kind: Pod
metadata:
  name: securityreview
spec:
  securityContext:
    runAsUser: 2100
  volumes:
    - name: cache
      emptyDir: {}
    - name: run
      emptyDir: {}
  containers:
  - name:  webguy
    image: nginx
    volumeMounts:
      - mountPath: /var/cache/nginx/
        name: cache
      - name: run
        mountPath: /var/run
    securityContext:
      runAsUser: 3000
      allowPrivilegeEscalation: false

@tranthepq said:
This is a bit tricky, look at the startup logs, we can found that the user does not have permission to write to /var/cache/nginx/ and /var/run

Not sure if this fix is valid to the exam

apiVersion: v1
kind: Pod
metadata:
  name: securityreview
spec:
  securityContext:
    runAsUser: 2100
  volumes:
    - name: cache
      emptyDir: {}
    - name: run
      emptyDir: {}
  containers:
  - name:  webguy
    image: nginx
    volumeMounts:
      - mountPath: /var/cache/nginx/
        name: cache
      - name: run
        mountPath: /var/run
    securityContext:
      runAsUser: 3000
      allowPrivilegeEscalation: false

Well, this does not work for me as it's not allowed to bind to port 80 as non root or am missing something?

I just went with this for two reasons, least time spent and its CKA not CKS so welp.
However, If I was at work presented with this would be a different story since I have dev and security teams. Also root is the only user on container with /bin/bash access that isn't /bin/false or nologin.
But that's my opinion since you could add a network policy and/or even build your own container.

apiVersion: v1
kind: Pod
metadata:
  name: securityreview
spec:
  containers:
  - name:  webguy
    image: nginx
    securityContext:
      runAsUser: 0
      allowPrivilegeEscalation: false

Great course, but I agree. This one is a bit too much of a trick question in my opinion. Just seems to lead to ambiguity. The question "find the proper id of the nginx user" really leads you to believe you are expected to run this as user 100.

Maybe a better example would be to take a different container image that can run as a different user than root? (create a local user for.. use DevDan for example) This would demonstrate that someone can indeed run a container as something other than root which is a common real use case for this out in the wild.

Hello,

Just had this issue, and indeed, I don't follow the point to use securityContext to run as root at the end.

Posted on bad topic: https://forum.linuxfoundation.org/discussion/comment/41555/#Comment_41555

For me, about checking .33, it say to check the uid of nginx.

Didn't make sense to check that if we use root at the end imo...

I have to give up this task, as I don't have a clear idea of which is the expected result.
In my case, I didn't get an error in /var/run mounting, and sysctls was not recognized. Maybe a new nginx image version has different parameters or I missed some points. In any case, I think I'm wasting my time trying to investigate this if I don't know the objective.