Linux Foundation CKS - Questions & Answers
Free preview · every answer includes a full explanation
Product page: https://prepkeys.com/cks.html
Simulation
Create a Pod name Nginx-pod inside the namespace testing, Create a service for the Nginx-pod named nginx-svc, using the ingress of your choice, run the ingress on tls, secure port.
Simulation
Create a new ServiceAccount named backend-sa in the existing namespace default, which has the capability to list the pods inside the namespace default.
Create a new Pod named backend-pod in the namespace default, mount the newly created sa backend-sa to the pod, and Verify that the pod is able to list pods.
Ensure that the Pod is running.
Simulation
Create a network policy named allow-np, that allows pod in the namespace staging to connect to port 80 of other pods in the same namespace.
Ensure that Network Policy:
1. Does not allow access to pod not listening on port 80.
2. Does not allow access from Pods, not in namespace staging.
Task

Analyze and edit the given Dockerfile /home/candidate/KSSC00301/Docker file (based on the ubuntu:16.04 image), fixing two instructions present in the file that are prominent security/best-practice issues.
Analyze and edit the given manifest file /home/candidate/KSSC00301/deployment.yaml, fixing two fields present in the file that are prominent security/best-practice issues.


Simulation
On the Cluster worker node, enforce the prepared AppArmor profile
1. #include <tunables/global>
2. profile nginx-deny flags=(attach_disconnected) {
3. #include <abstractions/base>
4. file,
5. # Deny all file writes.
6. deny /** w,
7. }
8. EOF'Edit the prepared manifest file to include the AppArmor profile.
1. apiVersion: v1
2. kind: Pod
3. metadata:
4. name: apparmor-pod
5. spec:
6. containers:
7. - name: apparmor-pod
8. image: nginx
Finally, apply the manifests files and create the Pod specified on it.
Verify: Try to make a file inside the directory which is restricted.
Simulation
Fix all issues via configuration and restart the affected components to ensure the new setting takes effect.
Fix all of the following violations that were found against the API server:
1. Ensure that the RotateKubeletServerCertificate argument is set to true.
2. Ensure that the admission control plugin PodSecurityPolicy is set.
3. Ensure that the --kubelet-certificate-authority argument is set as appropriate.
Fix all of the following violations that were found against the Kubelet:
1. Ensure the --anonymous-auth argument is set to false.
2. Ensure that the --authorization-mode argument is set to Webhook.
Fix all of the following violations that were found against the ETCD:-
1. Ensure that the --auto-tls argument is not set to true
2. Ensure that the --peer-auto-tls argument is not set to true
Hint: Take the use of Tool Kube-Bench
Simulation
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context dev
A default-deny NetworkPolicy avoid to accidentally expose a Pod in a namespace that doesn't have any other NetworkPolicy defined.
Task: Create a new default-deny NetworkPolicy named deny-network in the namespace test for all traffic of type Ingress + Egress
The new NetworkPolicy must deny all Ingress + Egress traffic in the namespace test.
Apply the newly created default-deny NetworkPolicy to all Pods running in namespace test.
You can find a skeleton manifests file at /home/cert_masters/network-policy.yaml
Simulation
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:
1. apiVersion: v1
2. kind: Pod
3. metadata:
4. name:
5. spec:
6. containers:
7. - name:
8. image:
9. volumeMounts:
10.- name:
11. mountPath:
12. volumes:
13.- name:
14. secret:
15. secretName:
Simulation
You must complete this task on the following cluster/nodes: Cluster: immutable-cluster
Master node: master1
Worker node: worker1
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context immutable-cluster
Context: It is best practice to design containers to be stateless and immutable.
Task:
Inspect Pods running in namespace prod and delete any Pod that is either not stateless or not immutable.
Use the following strict interpretation of stateless and immutable:
1. Pods being able to store data inside containers must be treated as not stateless.
Note: You don't have to worry whether data is actually stored inside containers or not already.
2. Pods being configured to be privileged in any way must be treated as potentially not stateless or not immutable.
Simulation
Secrets stored in the etcd is not secure at rest, you can use the etcdctl command utility to find the secret value
for e.g:-
ETCDCTL_API=3 etcdctl get /registry/secrets/default/cks-secret --cacert="ca.crt" -- cert="server.crt" --
key="server.key"
Output

Using the Encryption Configuration, Create the manifest, which secures the resource secrets using the provider AES-CBC and identity, to encrypt the secret-data at rest and ensure all secrets are encrypted with the new configuration.








