Linux Foundation CKS Exam - Topic 4 Question 74 Discussion

Actual exam question for Linux Foundation's CKS exam

Question #: 74
Topic #: 4

[All CKS Questions]

Create a PSP that will only allow the persistentvolumeclaim as the volume type in the namespace restricted.

Create a new PodSecurityPolicy named prevent-volume-policy which prevents the pods which is having different volumes mount apart from persistentvolumeclaim.

Create a new ServiceAccount named psp-sa in the namespace restricted.

Create a new ClusterRole named psp-role, which uses the newly created Pod Security Policy prevent-volume-policy

Create a new ClusterRoleBinding named psp-role-binding, which binds the created ClusterRole psp-role to the created SA psp-sa.

Hint:

Also, Check the Configuration is working or not by trying to Mount a Secret in the pod maifest, it should get failed.

POD Manifest:

apiVersion: v1

kind: Pod

metadata:

name:

spec:

containers:

- name:

image:

volumeMounts:

- name:

mountPath:

volumes:

- name:

secret:

secretName:

AExplanation:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we can provide it for defense in depth.
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that persistentVolumes set up by the cluster admin are safe to use.
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false

Show Suggested Answer

Suggested Answer: A

by Fanny at Feb 09, 2025, 06:04 AM

Limited Time Offer

25%

Off

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

Contribute your Thoughts:

Submit Cancel

Melinda

3 months ago

I thought secrets were essential for pods? Why can't we use them?

upvoted 0 times

...

Lynda

3 months ago

Nice, this should help tighten security in the namespace.

upvoted 0 times

...

Jade

4 months ago

Wait, can we really block all other volume types? Seems extreme.

upvoted 0 times

...

Janessa

4 months ago

Totally agree, this is a solid restriction.

upvoted 0 times

...

Alyce

4 months ago

Just a reminder, only persistentVolumeClaim is allowed here!

upvoted 0 times

...

Alesia

4 months ago

I recall testing the configuration by trying to mount a secret, but I’m not sure if the pod manifest needs to be structured a certain way for that to work.

upvoted 0 times

...

Amie

4 months ago

I’m a little confused about the annotations in the PSP. Do we need to include both seccomp and apparmor settings, or can we skip one?

upvoted 0 times

...

Rory

5 months ago

I practiced a similar question where we had to create a ServiceAccount and bind it to a role, so I feel confident about that part, but the specifics of the policy are a bit fuzzy.

upvoted 0 times

...

Jerlene

5 months ago

I think I remember that we need to define the PodSecurityPolicy with the right volume types, but I'm not entirely sure how to restrict it just to persistentvolumeclaim.

upvoted 0 times

...

Mattie

5 months ago

The hint at the end is a good way to verify the configuration is working as expected. I'll make sure to try that out once I've set everything up.

upvoted 0 times

...

Brett

5 months ago

Okay, I think I got this. First, create the PodSecurityPolicy to only allow the persistentvolumeclaim volume type. Then, create the ClusterRole and ClusterRoleBinding to associate it with the ServiceAccount. Should be able to test it by trying to mount a Secret volume.

upvoted 0 times

...

Diane

5 months ago

Hmm, not sure about the details of the Pod Security Policy and how to restrict the volume types. Might need to review the documentation carefully.

upvoted 0 times

...

Marta

5 months ago

This looks like a pretty straightforward task, just need to create the required resources and configure them properly.

upvoted 0 times

...

Tricia

10 months ago

I bet the secret volume type will still try to sneak in, like a secret agent in a spy movie. Gotta watch out for that!

upvoted 0 times

Walker

9 months ago

User 3: Yeah, like a secret agent trying to sneak in a secret volume type.

upvoted 0 times

...

Arlen

9 months ago

User 2: Nice, that should prevent any unauthorized volumes from sneaking in.

upvoted 0 times

...

Major

9 months ago

User 1: I set up the PodSecurityPolicy to only allow persistentvolumeclaim as the volume type.

upvoted 0 times

...

Timothy

10 months ago

Wait, so I have to create a whole new ServiceAccount, ClusterRole, and ClusterRoleBinding just to restrict the volume type? Seems a bit overkill, but I'll give it a shot.

upvoted 0 times

...

Lorenza

10 months ago

Hold on, does this mean I can't use any other volume types besides persistentVolumeClaim? That could be tricky for some of my applications.

upvoted 0 times

Diane

9 months ago

Make sure to check the logs for any errors when trying to mount a Secret. This restriction may require some adjustments in your application setup.

upvoted 0 times

...

Diane

9 months ago

You can try to mount a Secret in the pod manifest to test if the configuration is working. It should fail since only persistentVolumeClaim is allowed.

upvoted 0 times

...