Home / Linux Foundation / CKS

Question list

List of questions

Question 1

(0)

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 nam

Question 2

(0)

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:- a. Ensure t

Question 3

(0)

Create a PSP that will prevent the creation of privileged pods in the namespace. Create a new PodSecurityPolicy named prevent-privileged-policy which prevents the creation of privileged pods. Crea

Question 4

(0)

Context A Role bound to a Pod's ServiceAccount grants overly permissive permissions. Complete the following tasks to reduce the set of permissions. Task Given an existing Pod named web-pod runn

Question 5

(0)

Enable audit logs in the cluster, To Do so, enable the log backend, and ensure that 1. logs are stored at /var/log/kubernetes-logs.txt. 2. Log files are retained for 12 days. 3. at maximum, a num

Question 6

(0)

Analyze and edit the given Dockerfile FROM ubuntu:latest RUN apt-get update -y RUN apt-install nginx -y COPY entrypoint.sh / ENTRYPOINT ["/entrypoint.sh"] USER ROOT Fixing two instructions pr

Question 7

(0)

Create a RuntimeClass named gvisor-rc using the prepared runtime handler named runsc. Create a Pods of image Nginx in the Namespace server to run on the gVisor runtime class

Question 8

(0)

Task Create a NetworkPolicy named pod-access to restrict access to Pod users-service running in namespace dev-team. Only allow the following Pods to connect to Pod users-service: Pods in the na

Question 9

(0)

A container image scanner is set up on the cluster. Given an incomplete configuration in the directory /etc/kubernetes/confcontrol and a functional container image scanner with HTTPS endpoint ht

Question 10

(0)

On the Cluster worker node, enforce the prepared AppArmor profile #include <tunables/global> profile nginx-deny flags=(attach_disconnected) { #include <abstractions/base> file, # De

Related questions

Context AppArmor is enabled on the cluster's worker node. An AppArmor profile is prepared, but not enforced yet. Task On the cluster's worker node, enforce the prepared AppArmor profile located at /etc/apparmor.d/nginx_apparmor. Edit the prepared manifest file located at /home/candidate/KSSH00401/nginx-pod.yaml to apply the AppArmor profile. Finally, apply the manifest file and create the Pod specified in it.

Use the kubesec docker images to scan the given YAML manifest, edit and apply the advised changes, and passed with a score of 4 points. kubesec-test.yaml apiVersion: v1 kind: Pod metadata: name: kubesec-demo spec: containers: - name: kubesec-demo image: gcr.io/google-samples/node-hello:1.0 securityContext: readOnlyRootFilesystem: true Hint: docker run -i kubesec/kubesec:512c5e0 scan /dev/stdin < kubesec-test.yaml

Create a User named john, create the CSR Request, fetch the certificate of the user after approving it. Create a Role name john-role to list secrets, pods in namespace john Finally, Create a RoleBinding named john-role-binding to attach the newly created role john-role to the user john in the namespace john. To Verify: Use the kubectl auth CLI command to verify the permissions.

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.

Cluster: scanner Master node: controlplane Worker node: worker1 You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context scanner Given: You may use Trivy's documentation. Task: Use the Trivy open-source container scanner to detect images with severe vulnerabilities used by Pods in the namespace nato. Look for images with High or Critical severity vulnerabilities and delete the Pods that use those images. Trivy is pre-installed on the cluster's master node. Use cluster's master node to use Trivy.

Context A container image scanner is set up on the cluster, but it's not yet fully integrated into the cluster s configuration. When complete, the container image scanner shall scan for and reject the use of vulnerable images. Task Given an incomplete configuration in directory /etc/kubernetes/epconfig and a functional container image scanner with HTTPS endpoint https://wakanda.local:8081 /image_policy : 1. Enable the necessary plugins to create an image policy 2. Validate the control configuration and change it to an implicit deny 3. Edit the configuration to point to the provided HTTPS endpoint correctlyFinally, test if the configuration is working by trying to deploy the vulnerable resource /root/KSSC00202/vulnerable-resource.yml.

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.

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:- a. Ensure that the RotateKubeletServerCertificate argument is set to true. b. Ensure that the admission control plugin PodSecurityPolicy is set. c. Ensure that the --kubelet-certificate-authority argument is set as appropriate. Fix all of the following violations that were found against the Kubelet:- a. Ensure the --anonymous-auth argument is set to false. b. Ensure that the --authorization-mode argument is set to Webhook. Fix all of the following violations that were found against the ETCD:- a. Ensure that the --auto-tls argument is not set to true b. Ensure that the --peer-auto-tls argument is not set to true Hint: Take the use of Tool Kube-Bench

On the Cluster worker node, enforce the prepared AppArmor profile #include <tunables/global> profile nginx-deny flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } EOF' Edit the prepared manifest file to include the AppArmor profile. apiVersion: v1 kind: Pod metadata: name: apparmor-pod spec: containers: - name: apparmor-pod 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. Answer: See explanation below.

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:- a. Ensure the --authorization-mode argument includes RBAC b. Ensure the --authorization-mode argument includes Node c. Ensure that the --profiling argument is set to false Fix all of the following violations that were found against the Kubelet:- a. Ensure the --anonymous-auth argument is set to false. b. Ensure that the --authorization-mode argument is set to Webhook. Fix all of the following violations that were found against the ETCD:- a. Ensure that the --auto-tls argument is not set to true Hint: Take the use of Tool Kube-Bench

Question 2 - CKS discussion

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:- a. Ensure the --authorization-mode argument includes RBAC b. Ensure the --authorization-mode argument includes Node c. Ensure that the --profiling argument is set to false Fix all of the following violations that were found against the Kubelet:- a. Ensure the --anonymous-auth argument is set to false. b. Ensure that the --authorization-mode argument is set to Webhook.

Fix all of the following violations that were found against the ETCD:- a. Ensure that the --auto-tls argument is not set to true Hint: Take the use of Tool Kube-Bench

See the explanation

Suggested answer: A

Explanation:

API server:

Ensure the --authorization-mode argument includes RBAC

Turn on Role Based Access Control.

Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorization mode.

Fix - Buildtime

Kubernetes

apiVersion: v1

kind: Pod

metadata:

creationTimestamp: null

labels:

component: kube-apiserver

tier: control-plane

namespace: kube-system

spec:

containers:

- command:

+ - kube-apiserver

+ - --authorization-mode=RBAC,Node

image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0

livenessProbe:

failureThreshold: 8

httpGet:

host: 127.0.0.1

path: /healthz

port: 6443

scheme: HTTPS

initialDelaySeconds: 15

timeoutSeconds: 15

resources:

requests:

cpu: 250m

volumeMounts:

- mountPath: /etc/kubernetes/

readOnly: true

- mountPath: /etc/ssl/certs

- mountPath: /etc/pki

hostNetwork: true

volumes:

- hostPath:

path: /etc/kubernetes

- hostPath:

path: /etc/ssl/certs

- hostPath:

path: /etc/pki

Ensure the --authorization-mode argument includes Node

Remediation: Edit the API server pod specification file /etc/kubernetes/manifests/kubeapiserver.

yaml on the master node and set the --authorization-mode parameter to a value that

includes Node.

--authorization-mode=Node,RBAC

Audit:

/bin/ps -ef | grep kube-apiserver | grep -v grep

Expected result:

'Node,RBAC' has 'Node'

Ensure that the --profiling argument is set to false

Remediation: Edit the API server pod specification file /etc/kubernetes/manifests/kubeapiserver.

yaml on the master node and set the below parameter.

--profiling=false

Audit:

/bin/ps -ef | grep kube-apiserver | grep -v grep

Expected result:

'false' is equal to 'false'

Fix all of the following violations that were found against the Kubelet:-

Ensure the --anonymous-auth argument is set to false.

Remediation: If using a Kubelet config file, edit the file to set authentication: anonymous: enabled

to false. If using executable arguments, edit the kubelet service

file /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and set the

below parameter in KUBELET_SYSTEM_PODS_ARGS variable.

--anonymous-auth=false

Based on your system, restart the kubelet service. For example:

systemctl daemon-reload

systemctl restart kubelet.service

Audit:

/bin/ps -fC kubelet

Audit Config:

/bin/cat /var/lib/kubelet/config.yaml

Expected result:

'false' is equal to 'false'

2) Ensure that the --authorization-mode argument is set to Webhook.

Audit

docker inspect kubelet | jq -e '.[0].Args[] | match("--authorization-mode=Webhook").string'

Returned Value: --authorization-mode=Webhook

Fix all of the following violations that were found against the ETCD:-

a. Ensure that the --auto-tls argument is not set to true

Do not use self-signed certificates for TLS. etcd is a highly-available key value store used by

Kubernetes deployments for persistent storage of all of its REST API objects. These objects are

sensitive in nature and should not be available to unauthenticated clients. You should enable the

client authentication via valid certificates to secure the access to the etcd service.

Fix - Buildtime

Kubernetes

apiVersion: v1

kind: Pod

metadata:

annotations:

scheduler.alpha.kubernetes.io/critical-pod: ""

creationTimestamp: null

labels:

component: etcd

tier: control-plane

namespace: kube-system

spec:

containers:

- command:

+ - etcd

+ - --auto-tls=true

image: k8s.gcr.io/etcd-amd64:3.2.18

imagePullPolicy: IfNotPresent

livenessProbe:

exec:

command:

- /bin/sh

- -ec

- ETCDCTL_API=3 etcdctl --endpoints=https://[192.168.22.9]:2379 --

cacert=/etc/kubernetes/pki/etcd/ca.crt

--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --

key=/etc/kubernetes/pki/etcd/healthcheck-client.key

get foo

failureThreshold: 8

initialDelaySeconds: 15

timeoutSeconds: 15

resources: {}

volumeMounts:

- mountPath: /var/lib/etcd

- mountPath: /etc/kubernetes/pki/etcd

hostNetwork: true

priorityClassName: system-cluster-critical

volumes:

- hostPath:

path: /var/lib/etcd

type: DirectoryOrCreate

- hostPath:

path: /etc/kubernetes/pki/etcd

type: DirectoryOrCreate

status: {}

Explanation:

Show Answer

asked 18/09/2024

Michael Bays

33 questions

Your answer: A

0 comments

Sorted by