Lab 6.6 RBAC

aparajithanv

Hi,
I am having some trouble solving the lab 6.6. Here is my edited security-review1.yaml:

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

I have created securityaccount ServiceAccount, created ClusterRole with create, update, delete, list access to Pods. I have also done the role mapping.

Looking at the pod logs, I get these two errors:
[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)

What am I missing? Help is appreciated.

aparajithanv

Also, when I ran this command to login to the pod I get the following error:

$ kubectl exec -it securityreview -- sh
error: unable to upgrade connection: container not found ("webguy")

pbbhaskar

can you change/ edit runAsUser: 2000 to runAsUser: 0 and deploy it again?

nbon

I see the same error:

nbon

@pbbhaskar the lab tells us to shell into the container before changing the runAsUser.
but yes, runAsUser: 0 ultimately allowed me to progress.

chrispokorni

Hi @nbon,

The goal of the exercise is to find the correct user value for the security context that allows the container to run.

Regards,
-Chris

nbon

@chrispokorni how are we supposed to shell into the container?

serewicz

@nbon Use the kubectl exec -it command.

pbbhaskar

With runAsUser: 2000, the container does not even created. We need to know the correct value of runAsUser: element before running the kubectl exec -it command.

nbon

@serewicz I get the following error after using kubectl exec -it:
"error: unable to upgrade connection: container not found ("webguy")

serewicz

Hello,

If you look at the contents of the pod, what is the image it is trying to deploy? Could you run that image in some other way and look at the settings?

Regards,

mkevinmchugh

@serewicz - first thank you for tending this forum. It is very much appreciated.

I note in one of your replies that the exam will not tell students what to type. This is a valid observation.

I see that you referenced Section 6.1 as a map... that's where I started.

However, the nginx image lacks the commands needed to follow that as a map.

So, I added busybox. But, the pod only runs with busybox in it. But, I have zero way to understand if this is a correct solution. It doesn't seem correct.

While I understand "pushing" students to figure things out, there isn't even enough context to figure out how to figure it out.

Could you explain a couple fundamental concepts so that I/we can arrive the the understanding to tackle this task.

mkevinmchugh

@serewicz I have found two ways to get this to run without adding another container. Neither involved the kubectl exec command because the nginx image does not have the commands in the shell required to determine the required userid.

The key is understanding the required userid. Lab 6.1 should work IF the image had the required commands. The current image does not. This still leaves the problem as to how to determine the correct userid.

The problem with using another image is that the required behavior (permissions) are changed when another image is used. So, that debug path is no good.

We could try to install ps or find other ways to get the id. That seems way out of the way.

So, this folds back to ... what is the right id number to use and in which security context stanza should it be set?

While it is not obvious, determining the required userid is the filter to use when reviewing Chapter 6's materials to solve this problem.

lsolovey

Hello everyone, I'm also very curious what is the right solution for running nginx in Lab 6.6.

Hello,

If you look at the contents of the pod, what is the image it is trying to deploy? Could you run that image in some other way and look at the settings?

@serewicz Following your hint above, I ran nginx image in Docker and determined that it runs as **root **user:

$ docker run -it --entrypoint whoami nginx
root

So, does that mean that we should set runAsUser: 0 ? Is that the expected solution for this exercise?

I'm slightly confused because this solution (set runAsUser: 0), although technically valid, defeats the purpose of securityContext, doesn't it?

On the other hand, running nginx as non-root user requires extra work and extra knowledge of nginx. See https://github.com/docker-library/docs/tree/master/nginx#running-nginx-as-a-non-root-user

So I doubt that this lab 6.6 expects students to go into such internals of nginx configuration.

@serewicz Please advise. Thank you so much in advance!

ibanez

Hi all,
I logged in to the container removing the user policies, then I installed proper package to show the process (procps), and finally ps says there are 3 processes with two users:

• user 0 (root) for master process
• user 101 (nginx) for worker processes

Regards,
JI

giuliengi87

Hello i am facing the same issue can someone please post a working solution? Do i have to disable the securityContext and then manually install the ps command into the container to check the right id? (seem very unlikely to me)