Linux Foundation Certified Kubernetes Security Specialist (CKS) - CKS무료 덤프문제 풀어보기
SIMULATION
You must complete this task on the following cluster/nodes:
Cluster: trace
Master node: master
Worker node: worker1
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context trace
Given: You may use Sysdig or Falco documentation.
Task:
Use detection tools to detect anomalies like processes spawning and executing something weird frequently in the single container belonging to Pod tomcat.
Two tools are available to use:
1. falco
2. sysdig
Tools are pre-installed on the worker1 node only.
Analyse the container's behaviour for at least 40 seconds, using filters that detect newly spawning and executing processes.
Store an incident file at /home/cert_masters/report, in the following format:
[timestamp],[uid],[processName]
Note: Make sure to store incident file on the cluster's worker node, don't move it to master node.
You must complete this task on the following cluster/nodes:
Cluster: trace
Master node: master
Worker node: worker1
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context trace
Given: You may use Sysdig or Falco documentation.
Task:
Use detection tools to detect anomalies like processes spawning and executing something weird frequently in the single container belonging to Pod tomcat.
Two tools are available to use:
1. falco
2. sysdig
Tools are pre-installed on the worker1 node only.
Analyse the container's behaviour for at least 40 seconds, using filters that detect newly spawning and executing processes.
Store an incident file at /home/cert_masters/report, in the following format:
[timestamp],[uid],[processName]
Note: Make sure to store incident file on the cluster's worker node, don't move it to master node.
정답:
See the Explanation below
Explanation:
$vim /etc/falco/falco_rules.local.yaml
- rule: Container Drift Detected (open+create)
desc: New executable created in a container due to open+create
condition: >
evt.type in (open,openat,creat) and
evt.is_open_exec=true and
container and
not runc_writing_exec_fifo and
not runc_writing_var_lib_docker and
not user_known_container_drift_activities and
evt.rawres>=0
output: >
%evt.time,%user.uid,%proc.name # Add this/Refer falco documentation
priority: ERROR
$kill -1 <PID of falco>
Explanation:
[desk@cli] $ ssh node01
[node01@cli] $ vim /etc/falco/falco_rules.yaml
search for Container Drift Detected & paste in falco_rules.local.yaml
[node01@cli] $ vim /etc/falco/falco_rules.local.yaml
- rule: Container Drift Detected (open+create)
desc: New executable created in a container due to open+create
condition: >
evt.type in (open,openat,creat) and
evt.is_open_exec=true and
container and
not runc_writing_exec_fifo and
not runc_writing_var_lib_docker and
not user_known_container_drift_activities and
evt.rawres>=0
output: >
%evt.time,%user.uid,%proc.name # Add this/Refer falco documentation
priority: ERROR
[node01@cli] $ vim /etc/falco/falco.yaml
Explanation:
$vim /etc/falco/falco_rules.local.yaml
- rule: Container Drift Detected (open+create)
desc: New executable created in a container due to open+create
condition: >
evt.type in (open,openat,creat) and
evt.is_open_exec=true and
container and
not runc_writing_exec_fifo and
not runc_writing_var_lib_docker and
not user_known_container_drift_activities and
evt.rawres>=0
output: >
%evt.time,%user.uid,%proc.name # Add this/Refer falco documentation
priority: ERROR
$kill -1 <PID of falco>
Explanation:
[desk@cli] $ ssh node01
[node01@cli] $ vim /etc/falco/falco_rules.yaml
search for Container Drift Detected & paste in falco_rules.local.yaml
[node01@cli] $ vim /etc/falco/falco_rules.local.yaml
- rule: Container Drift Detected (open+create)
desc: New executable created in a container due to open+create
condition: >
evt.type in (open,openat,creat) and
evt.is_open_exec=true and
container and
not runc_writing_exec_fifo and
not runc_writing_var_lib_docker and
not user_known_container_drift_activities and
evt.rawres>=0
output: >
%evt.time,%user.uid,%proc.name # Add this/Refer falco documentation
priority: ERROR
[node01@cli] $ vim /etc/falco/falco.yaml
SIMULATION
Create a RuntimeClass named untrusted using the prepared runtime handler named runsc.
Create a Pods of image alpine:3.13.2 in the Namespace default to run on the gVisor runtime class.
Create a RuntimeClass named untrusted using the prepared runtime handler named runsc.
Create a Pods of image alpine:3.13.2 in the Namespace default to run on the gVisor runtime class.
정답:
See the Explanation belowExplanation:
SIMULATION
Given an existing Pod named nginx-pod running in the namespace test-system, fetch the service-account-name used and put the content in /candidate/KSC00124.txt Create a new Role named dev-test-role in the namespace test-system, which can perform update operations, on resources of type namespaces.
Create a new RoleBinding named dev-test-role-binding, which binds the newly created Role to the Pod's ServiceAccount ( found in the Nginx pod running in namespace test-system).
Given an existing Pod named nginx-pod running in the namespace test-system, fetch the service-account-name used and put the content in /candidate/KSC00124.txt Create a new Role named dev-test-role in the namespace test-system, which can perform update operations, on resources of type namespaces.
Create a new RoleBinding named dev-test-role-binding, which binds the newly created Role to the Pod's ServiceAccount ( found in the Nginx pod running in namespace test-system).
정답:
See the Explanation belowExplanation:
SIMULATION
Context:
Cluster: gvisor
Master node: master1
Worker node: worker1
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context gvisor
Context: This cluster has been prepared to support runtime handler, runsc as well as traditional one.
Task:
Create a RuntimeClass named not-trusted using the prepared runtime handler names runsc.
Update all Pods in the namespace server to run on newruntime.
Context:
Cluster: gvisor
Master node: master1
Worker node: worker1
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context gvisor
Context: This cluster has been prepared to support runtime handler, runsc as well as traditional one.
Task:
Create a RuntimeClass named not-trusted using the prepared runtime handler names runsc.
Update all Pods in the namespace server to run on newruntime.
정답:
See the Explanation below
Explanation:
Explanation:
[desk@cli] $vim runtime.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: not-trusted
handler: runsc
[desk@cli] $ k apply -f runtime.yaml
[desk@cli] $ k get pods
NAME READY STATUS RESTARTS AGE
nginx-6798fc88e8-chp6r 1/1 Running 0 11m
nginx-6798fc88e8-fs53n 1/1 Running 0 11m
nginx-6798fc88e8-ndved 1/1 Running 0 11m
[desk@cli] $ k get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 3/3 11 3 5m
[desk@cli] $ k edit deploy nginx
Explanation:
Explanation:
[desk@cli] $vim runtime.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: not-trusted
handler: runsc
[desk@cli] $ k apply -f runtime.yaml
[desk@cli] $ k get pods
NAME READY STATUS RESTARTS AGE
nginx-6798fc88e8-chp6r 1/1 Running 0 11m
nginx-6798fc88e8-fs53n 1/1 Running 0 11m
nginx-6798fc88e8-ndved 1/1 Running 0 11m
[desk@cli] $ k get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 3/3 11 3 5m
[desk@cli] $ k edit deploy nginx
SIMULATION
Documentation Deployments, Pods, Falco
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000026
Context
A Pod is misbehaving and poses a security threat to the system.
Task
One of the Pods belonging to the application ollama is misbehaving. It is directly accessing the system's memory reading from the sensitive file /dev/mem.
First, identify the misbehaving Pod accessing /dev/mem.
The cluster uses the Docker Engine as its container runtime . If needed, use the docker command to troubleshoot running containers.
Next, identify the Deployment managing the misbehaving Pod and scale it to zero replicas.
Do not modify the Deployment except for scaling it down.
Do not modify any other Deployments .
Do not delete any Deployments.
Documentation Deployments, Pods, Falco
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000026
Context
A Pod is misbehaving and poses a security threat to the system.
Task
One of the Pods belonging to the application ollama is misbehaving. It is directly accessing the system's memory reading from the sensitive file /dev/mem.
First, identify the misbehaving Pod accessing /dev/mem.
The cluster uses the Docker Engine as its container runtime . If needed, use the docker command to troubleshoot running containers.
Next, identify the Deployment managing the misbehaving Pod and scale it to zero replicas.
Do not modify the Deployment except for scaling it down.
Do not modify any other Deployments .
Do not delete any Deployments.
정답:
See the Explanation below for complete solution
Explanation:
1) Connect to the correct host
ssh cks000026
sudo -i
2) Identify the misbehaving Pod accessing /dev/mem
This task hints Falco is available → use it first (fast + intended).
2.1 Check Falco logs for /dev/mem access
journalctl -u falco | grep dev/mem
If Falco runs as a pod instead of systemd:
kubectl -n falco logs -l app=falco | grep dev/mem
2.2 Identify the Pod name
From the Falco output, you will see something like:
Pod=ollama-xxxxx Namespace=default File=/dev/mem
Note the exact Pod name (example: ollama-7c9d6f7b6d-abcde)
3) (If Falco logs are unclear) Confirm using Docker runtime
Because the cluster uses Docker, verify which container is accessing /dev/mem.
3.1 List running containers
docker ps
3.2 Inspect suspicious container
(Find container related to ollama)
docker inspect <container_id> | grep ollama
You should confirm it maps to the same Pod you saw in Falco.
4) Identify the Deployment managing the misbehaving Pod
4.1 Get Pod details
kubectl get pod <MISBEHAVING_POD_NAME> -o wide
4.2 Find owning Deployment
kubectl get pod <MISBEHAVING_POD_NAME> -o jsonpath='{.metadata.ownerReference[0].name}' This will output something like:
ollama
That is the Deployment name
5) Scale ONLY that Deployment to zero replicas
Do not edit, delete, or touch anything else
kubectl scale deployment ollama --replicas=0
6) Verify the Pod is terminated
kubectl get pods | grep ollama
Expected: no running Pods
Also confirm replicas:
kubectl get deployment ollama
Replicas should show:
0/0
Explanation:
1) Connect to the correct host
ssh cks000026
sudo -i
2) Identify the misbehaving Pod accessing /dev/mem
This task hints Falco is available → use it first (fast + intended).
2.1 Check Falco logs for /dev/mem access
journalctl -u falco | grep dev/mem
If Falco runs as a pod instead of systemd:
kubectl -n falco logs -l app=falco | grep dev/mem
2.2 Identify the Pod name
From the Falco output, you will see something like:
Pod=ollama-xxxxx Namespace=default File=/dev/mem
Note the exact Pod name (example: ollama-7c9d6f7b6d-abcde)
3) (If Falco logs are unclear) Confirm using Docker runtime
Because the cluster uses Docker, verify which container is accessing /dev/mem.
3.1 List running containers
docker ps
3.2 Inspect suspicious container
(Find container related to ollama)
docker inspect <container_id> | grep ollama
You should confirm it maps to the same Pod you saw in Falco.
4) Identify the Deployment managing the misbehaving Pod
4.1 Get Pod details
kubectl get pod <MISBEHAVING_POD_NAME> -o wide
4.2 Find owning Deployment
kubectl get pod <MISBEHAVING_POD_NAME> -o jsonpath='{.metadata.ownerReference[0].name}' This will output something like:
ollama
That is the Deployment name
5) Scale ONLY that Deployment to zero replicas
Do not edit, delete, or touch anything else
kubectl scale deployment ollama --replicas=0
6) Verify the Pod is terminated
kubectl get pods | grep ollama
Expected: no running Pods
Also confirm replicas:
kubectl get deployment ollama
Replicas should show:
0/0
SIMULATION
Service is running on port 389 inside the system, find the process-id of the process, and stores the names of all the open-files inside the /candidate/KH77539/files.txt, and also delete the binary.
Service is running on port 389 inside the system, find the process-id of the process, and stores the names of all the open-files inside the /candidate/KH77539/files.txt, and also delete the binary.
정답:
See the Explanation belowExplanation:
root# netstat -ltnup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 1293/dropbox tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 1293/dropbox tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd tcp 0 0 127.0.0.1:9393 0.0.0.0:* LISTEN 900/perl tcp 0 0 :::80 :::* LISTEN 9583/docker-proxy tcp 0 0 :::443 :::* LISTEN 9571/docker-proxy udp 0 0 0.0.0.0:68 0.0.0.0:* 8822/dhcpcd
...
root# netstat -ltnup | grep ':22'
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd
The ss command is the replacement of the netstat command.
Now let's see how to use the ss command to see which process is listening on port 22:
root# ss -ltnup 'sport = :22'
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:("sshd",pid=575,fd=3))
root# netstat -ltnup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 1293/dropbox tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 1293/dropbox tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd tcp 0 0 127.0.0.1:9393 0.0.0.0:* LISTEN 900/perl tcp 0 0 :::80 :::* LISTEN 9583/docker-proxy tcp 0 0 :::443 :::* LISTEN 9571/docker-proxy udp 0 0 0.0.0.0:68 0.0.0.0:* 8822/dhcpcd
...
root# netstat -ltnup | grep ':22'
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd
The ss command is the replacement of the netstat command.
Now let's see how to use the ss command to see which process is listening on port 22:
root# ss -ltnup 'sport = :22'
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:("sshd",pid=575,fd=3))
SIMULATION
Two tools are pre-installed on the cluster's worker node:
Using the tool of your choice (including any non pre-installed tool), analyze the container's behavior for at least 30 seconds, using filters that detect newly spawning and executing processes.
Store an incident file at /opt/KSRS00101/alerts/details, containing the detected incidents, one per line, in the following format:
The following example shows a properly formatted incident file:
Two tools are pre-installed on the cluster's worker node:
Using the tool of your choice (including any non pre-installed tool), analyze the container's behavior for at least 30 seconds, using filters that detect newly spawning and executing processes.
Store an incident file at /opt/KSRS00101/alerts/details, containing the detected incidents, one per line, in the following format:
The following example shows a properly formatted incident file:
정답:
See explanation below
Explanation:
Explanation: