What is the idea behind finding the correct nginx uid and fixing the pod? If I changed the security context to 101(nginx uid) it still fails.
I think that it is about setting the uid to root so it can boot. I did set both user and group to 0 (root) and then the pod would run successfully.
Indeed, sometimes changing the UID may be an answer, but then the application running inside the container would fail. As a result you may have to change the security context. Security context may be set via an admission controller, not the developer of the application, which may then conflict with the way the container was configured. As a result one or the other would need to be modified if the goal is to have the pod running.
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.
Could you elaborate this a little more @serewicz ?
As @kareldebeus pointed out: setting runAsUser =0 allows the Pod to start but defeats the purpose of a securityContext which should normally restrict access. I find that confusing. Is there more behind answering question 33 than we currently see? Or is runAsUser=0 the correct answer?
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
- name: webguy
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!
If you were required to always have a security context, but someone else had set the wrong security context, how would you fix the problem such that the pod runs but you are meeting the security team requirement that there is a security context set for the pod?
I'm also confused by this question. It states "After finding the errors, log into the container and find the proper id of the nginx user". I am assuming by "login" you mean attach to it? How are we supposed to attach to it if its not running?
If not, then this question is very badly worded. I have no idea what it's asking me to do.
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".
Thanks for your feedback.
You realize the whole point of the domain review is to give less than all information such that you are testing your own knowledge and ability to function as a system administrator would be called upon to do. correct?
You do realize the exam will not tell you what to type, and that you will have to understand more than following along and figure out what needs to be fixed or configured, correct?