Linux Foundation CKS Exam - Topic 1 Question 42 Discussion

Actual exam question for Linux Foundation's CKS exam

Question #: 42
Topic #: 1

[All CKS Questions]

Context: Cluster:prod Master node:master1 Worker node:worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $kubectl config use-context prod

Task: Analyse and edit the given Dockerfile (based on theubuntu:18:04image) /home/cert_masters/Dockerfilefixing two instructions present in the file being prominent security/best-practice issues.

Analyse and edit the given manifest file /home/cert_masters/mydeployment.yamlfixing two fields present in the file being prominent security/best-practice issues.

Note:Don't add or remove configuration settings; only modify the existing configuration settings, so that two configuration settings each are no longer security/best-practice concerns. Should you need an unprivileged user for any of the tasks, use usernobodywith user id65535

AExplanation:
1. For Dockerfile:Fix the image version & user name in Dockerfile
2. For mydeployment.yaml : Fix security contexts
Explanation
[desk@cli] $vim /home/cert_masters/Dockerfile
FROM ubuntu:latest # Remove this
FROM ubuntu:18.04 # Add this
USER root # Remove this
USER nobody # Add this
RUN apt get install -y lsof=4.72 wget=1.17.1 nginx=4.2
ENV ENVIRONMENT=testing
USER root # Remove this
USER nobody # Add this
CMD ['nginx -d']

[desk@cli] $vim/home/cert_masters/mydeployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: kafka
name: kafka
spec:
replicas: 1
selector:
matchLabels:
app: kafka
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: kafka
spec:
containers:
- image: bitnami/kafka
name: kafka
volumeMounts:
- name: kafka-vol
mountPath: /var/lib/kafka
securityContext:
{'capabilities':{'add':['NET_ADMIN'],'drop':['all']},'privileged': True,'readOnlyRootFilesystem': False, 'runAsUser': 65535} # Delete This
{'capabilities':{'add':['NET_ADMIN'],'drop':['all']},'privileged': False,'readOnlyRootFilesystem': True, 'runAsUser': 65535} # Add This
resources: {}
volumes:
- name: kafka-vol
emptyDir: {}
status: {}
Pictorial View:
[desk@cli] $vim/home/cert_masters/mydeployment.yaml

Show Suggested Answer

Suggested Answer: A

by Nana at Oct 05, 2023, 04:25 AM

Limited Time Offer

25%

Off

Get Premium CKS Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

Submit Cancel

Kallie

3 months ago

I thought privileged mode was necessary for Kafka. Surprised to see it removed!

upvoted 0 times

...

Iola

3 months ago

Good call on the security context changes!

upvoted 0 times

...

Katie

4 months ago

Wait, why are we using USER nobody? Isn't that too restrictive?

upvoted 0 times

...

Letha

4 months ago

Agreed, using the latest version can be risky.

upvoted 0 times

...

Billye

4 months ago

Gotta fix that Dockerfile to use ubuntu:18.04!

upvoted 0 times

...

Cristy

4 months ago

For the manifest file, I think we should also ensure that the 'runAsUser' is set correctly. I remember that was a key point in our last practice question.

upvoted 0 times

...

Glenn

4 months ago

I feel a bit confused about the Dockerfile edits. I know we need to use 'USER nobody', but I can't recall if we should remove all instances of 'USER root'.

upvoted 0 times

...

Alonzo

5 months ago

I remember we practiced something similar where we had to adjust security contexts in a YAML file. I think we should set 'privileged' to false and make the filesystem read-only.

upvoted 0 times

...

Frank

5 months ago

I think for the Dockerfile, we definitely need to change the base image to a specific version like ubuntu:18.04, but I'm not entirely sure about the user context.

upvoted 0 times

...

Nieves

5 months ago

I'm a little worried about the security implications here. I'll need to be extra careful to ensure I'm addressing the right concerns and not introducing any new vulnerabilities.

upvoted 0 times

...

Lelia

5 months ago

I feel pretty confident about this one. The instructions are clear, and I've worked with Dockerfiles and Kubernetes manifests before. I think I can knock this out without too much trouble.

upvoted 0 times

...

An

5 months ago

Okay, let's break this down step-by-step. First, I'll check the Dockerfile and look for the image version and user name issues. Then I'll tackle the security context problems in the manifest file.

upvoted 0 times

...

Crista

5 months ago

Hmm, I'm a bit unsure about the specifics of the security concerns here. I'll need to review the documentation on best practices for Dockerfiles and Kubernetes manifests.

upvoted 0 times

...

An

5 months ago

This looks like a tricky one. I'll need to carefully analyze the Dockerfile and manifest file to identify the security/best-practice issues.

upvoted 0 times

...

Belen

5 months ago

Okay, I've got this. The key is to leverage modern monitoring tools and data sources to get better visibility. Streaming telemetry and APIs are the way to go, rather than relying on legacy protocols.

upvoted 0 times

...

Buck

5 months ago

This looks like a tricky one, but I think I can work through it step-by-step.

upvoted 0 times

...

Yaeko

5 months ago

I'm a bit unsure about this one. I know we need to compile the different asset types, but I'm not sure of the exact order. Maybe I should review the SFRA documentation again to be sure.

upvoted 0 times

...

Norah

5 months ago

Hmm, I'm a bit unsure about this one. I'll need to think it through carefully to make sure I understand the difference between identification, authentication, and authorization.

upvoted 0 times

...