# Task 1 A pod called redis-backend has been created in the prod-x12cs namespace. It has been exposed as a service of type ClusterIP. The pod listens on TCP port 6379. Create a network policy called allow-redis-access to lock down access to this pod only for the following: Any pod in the same namespace with the label backend=prod-x12cs All pods in the prod-yx13cs namespace Ensure that traffic is only allowed on TCP port 6379. All other incoming connections should be blocked. Use the existing labels when creating the network policy. Is Network Policy applied on the correct pods? Is the incoming traffic allowed from pods in prod-yx13cs namespace? Is the incoming traffic allowed from pods with label backend=prod-x12cs ? Is the ingress traffic restricted to port 6379? # Task 2 There is an existing CiliumNetworkPolicy default-allow in the namespace team-azure, which allows all traffic. In the namespace team-azure, create a CiliumNetworkPolicy as follows: Create a Layer 3 policy named p1 that denies outgoing traffic from Pods with the label role=messenger to Pods with the label role=database. Is the cilium policy created ? Is the cilium network policy working as expected? # Task 3 A pod named apps-cluster-dash has been created in the gamma namespace using a service account called cluster-view. This service account has been granted additional permissions as compared to the default service account and can view resources cluster-wide on this Kubernetes cluster. While these permissions are important for the application in this pod to work, the secret token is still mounted on this pod. Secure the pod in such a way that the secret token is no longer mounted on this pod. You may delete and recreate the pod. Is the pod created with a cluster-view service account? Is the secret token not mounted in the pod? # Task 4 A pod in the sahara namespace has generated alerts that a shell was opened inside the container. To recognize such alerts, set the priority to ALERT and change the format of the output so that it looks like the below: ALERT timestamp of the event without nanoseconds,User ID,the container id,the container image repository Make sure to update the rule such that the changes persist across Falco updates. You can refer the falco documentation Here Are the rules updated according to the new format? Is falco running? # Task 5 martin is a developer who needs access to work on the dev-a, dev-b, and dev-z namespaces. He should be able to perform any operation on any pod in the dev-a and dev-b namespaces. However, in the dev-z namespace, he should only have permission to get and list the pods. The current setup is too permissive and violates the above condition. Use the above requirement to secure martin's access in the cluster. You may re-create objects, but ensure they retain their existing names. Does martin have unrestricted access to all pods in dev-a? Does martin have unrestricted access to all pods in dev-b? Can martin only list and get pods in dev-z? # Task 6 There is a deployment named hacker in the namespace team-red, which mounts /run/containerd as a hostPath volume on the Node where it's running. This means that the Pod can access various data about other containers running on the same Node. To prevent this, configure the team-red namespace to enforce the baseline Pod Security Standard. Once completed, delete the Pod from the deployment mentioned above. Check the ReplicaSet events and write the event lines containing the reason why the Pod isn't recreated into /opt/course/logs.txt. Note: You may see multiple identical event lines with the same error. Paste only one of them in the logs.txt file - preferably the last one. Is the pod in the team-red namespace deleted? Are the replicaset events written to /opt/course/logs.txt? # Task 7 There is a Dockerfile named unsecure.Dockerfile located at /opt/course/image/. DevSecOps has asked you to improve this image by: Changing the base image to alpine:3.12 Not installing curl Updating nginx to use the version constraint >=1.18.0 Running the main process as user myuser Do not add any new lines to the Dockerfile - only modify the existing ones. Is the Dockerfile modified? # Task 8 A pod definition file has been created at /root/CKS/simple-pod.yaml . Use the kubesec tool to generate a report for this pod definition file and fix the major issues so that the subsequent scan passes. Once done, generate the report again and save it to the file /root/CKS/kubesec-report.txt Is the pod definition file fixed? Is the pass report generated and saved at /root/CKS/kubesec-report.txt? # Task 9 There is a deployment named rocket-server, which is exposed by a service of the same name in the space namespace. Create an ingress resource named rocket-ingress to load balance the incoming traffic to the workload on path /. Use the hostname rocket-server.local for the Ingress rules. Use the TLS certificate stored in the rocket-tls secret in the space namespace to enable TLS traffic on the ingress resource. Make sure to add the IP of the Ingress Nginx controller matching the rocket-server.local DNS to the /etc/hosts file. Note: This cluster has no external load balancer provider, so the EXTERNAL-IP of the ingress-nginx-controller service will stay in the state - this is expected. Use the IP under the CLUSTER-IP column of that service for the /etc/hosts entry. Is the ingress resource correctly created? Has the ingress TLS secret been attached? Does the ingress route to the correct path and port? Is curl working for the HTTPS connection via the ingress? # Task 10 Create a new pod called audit-nginx in the default namespace using the nginx image. Secure the syscalls that this pod can use by using the audit.json seccomp profile in the pod's security context. The audit.json file is located in the /root/CKS directory. Before creating the pod, move the file to the profiles directory inside the default seccomp directory. Does audit-nginx use the right image? Is the pod running? Does the pod use the correct seccomp profile? # Task 11 A deployment named fruits in the namespace salad has three containers: apple banana, and kiwi One of these containers has the package curl installed. Identify which container has that package from the running containers, and create an SBOM SPDX for the container's image. Use the tarball archive of that particular image stored under /root/ImageTarballs directory for generating the SPDX JSON. The archives have names matching their images. Save the output in ~/bugged-fruit.spdx. Save the container name in ~/bugged-container.txt. Note: bom and all its required dependencies are already installed. Is SPDX JSON SBOM for the image with curl installed, stored at ~/bugged-fruit.spdx? Is the container name stored in ~/bugged-container.txt? # Task 12 Enable auditing on this cluster using a basic policy file located at /etc/kubernetes/cluster-policy.yaml. Configure the logs to be stored at /var/log/cluster-audit.log and retained for 10 days. The maximum size should be 10MB, and up to 3 files should be kept at a time. After enabling auditing on the cluster, update the basic policy file to track the following: Delete activity on secrets in the kube-system namespace at the Metadata level Changes to deployments in the default namespace at the Request level All other requests at the Metadata level Ensure that the updated policy file is applied and in effect. Note: A copy of the kube-apiserver.yaml is available in ~/ so you can revert if the configuration goes wrong. Ensure that the kube-apiserver is working correctly, as it will be required for grading the exam. Does /var/log/cluster-audit.log exist with the logs written to it? Does auditing follow the mentioned parameters as specified in the question? Is the delete activity on secrets tracked at the Metadata level in the kube-system namespace? Is the edit activity on deployments tracked at the Request level in the default namespace? # Task 13 A pod has been created in the omni namespace, but it has a couple of issues. The pod has been created with more permissions than it needs. It allows read access in the /usr/share/nginx/html/internal directory, opening the internal site to be accessed publicly. To verify this, click the Site button (above the terminal) and add /internal/ to the end of the URL. Use the below recommendations to fix this: Use the AppArmor profile created at /etc/apparmor.d/frontend to restrict the internal site. Several service accounts exist in the omni namespace. Apply the principle of least privilege to select the service account with the minimum privileges (excluding the default service account). Recreate the pod with the correct service account, and then delete the other unused service accounts in the omni namespace (excluding the default service account). You can recreate the pod, but do not create a new service account and do not use the default service account. Is the correct service account used? Are the obsolete service accounts deleted? Is the internal-site restricted? Is the pod running? # Task 14 The namespace encrypted has two applications, alpha and beta. Since these applications handle critical communications, enforce strict mTLS using Istio in the encrypted namespace. Make sure that the workloads have the istio sidecar injected. Note: istio and istioctl have already been installed for you. Has the istio-proxy sidecar been injected for the alpha deployment? Has the istio-proxy sidecar been injected for the beta deployment? Has the STRICT mTLS policy been applied? # Task 15 In the namespace code, create a TLS secret code-secret with the following certificate and key provided: cert: /root/custom-cert.crt key: /root/custom-key.key Attach that secret as a volume named secret-volume in the deployment code-server. Is the code-secret secret created in the namespace code with the mentioned specs? Is the secret mounted as a volume on the container in the deployment code-server? ## solution ```bash kubectl create secret tls code-secret -n code --cert=/root/custom-cert.crt --key=/root/custom-key.key