242 lines
10 KiB
Markdown
242 lines
10 KiB
Markdown
# 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 <pending> 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 |