CKS試験無料問題集「Linux Foundation Certified Kubernetes Security Specialist (CKS) 認定」
SIMULATION
Documentation Deployment, Pod, Namespace
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000028
Context
You must update an existing Pod to ensure the immutability of its containers.
Task
Modify the existing Deployment named lamp-deployment, running in namespace lamp, so that its containers:
. run with user ID 20000
. use a read-only root filesystem
. forbid privilege escalation
The Deployment's manifest file con be found at /home/candidate/finer-sunbeam/lamp-deployment.yaml.
Documentation Deployment, Pod, Namespace
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000028
Context
You must update an existing Pod to ensure the immutability of its containers.
Task
Modify the existing Deployment named lamp-deployment, running in namespace lamp, so that its containers:
. run with user ID 20000
. use a read-only root filesystem
. forbid privilege escalation
The Deployment's manifest file con be found at /home/candidate/finer-sunbeam/lamp-deployment.yaml.
正解：
See the Explanation below for complete solution
Explanation:
1) Connect to the correct host
ssh cks000028
sudo -i
2) Use the right kubeconfig (safe in exam)
export KUBECONFIG=/etc/kubernetes/admin.conf
3) Open the provided Deployment manifest
vi /home/candidate/finer-sunbeam/lamp-deployment.yaml
4) Edit ONLY the Pod template security settings (add/modify these fields) Inside:
spec: -> template: -> spec:
4.1 Set container to run as user 20000
Add (or change) under the container securityContext::
securityContext:
runAsUser: 20000
4.2 Make root filesystem read-only
In the SAME container securityContext: ensure:
readOnlyRootFilesystem: true
4.3 Forbid privilege escalation
In the SAME container securityContext: ensure:
allowPrivilegeEscalation: false
✅ The container section should look like this (example - keep your existing image/ports/etc):
spec:
template:
spec:
containers:
- name: <your-container-name>
image: <unchanged>
securityContext:
runAsUser: 20000
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
If there are multiple containers, apply the same securityContext to each container.
Save and exit:
:wq
5) Apply the manifest (updates Deployment -> recreates Pods)
kubectl -n lamp apply -f /home/candidate/finer-sunbeam/lamp-deployment.yaml
6) Wait for rollout
kubectl -n lamp rollout status deployment/lamp-deployment
7) Verify the security settings are live
7.1 Check the Pod is running
kubectl -n lamp get pods -l app=lamp -o wide
(if label differs, just kubectl -n lamp get pods)
7.2 Verify the three fields on a running Pod
Pick the Pod name and run:
POD=$(kubectl -n lamp get pods -o jsonpath='{.items[0].metadata.name}') kubectl -n lamp get pod $POD -o jsonpath='{.spec.containers[0].securityContext.runAsUser}{"\n"}{.spec.containers[0].securityContext.readOnlyRootFilesystem}{"\n"}{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}' Expected output:
20000
true
false
If the pod fails after readOnlyRootFilesystem=true
Don't change the requirement (task demands it). Usually the app needs writable dirs via volumes, but the task doesn't ask for that-so only adjust if the manifest already has volumes and just needs these securityContext fields.
Explanation:
1) Connect to the correct host
ssh cks000028
sudo -i
2) Use the right kubeconfig (safe in exam)
export KUBECONFIG=/etc/kubernetes/admin.conf
3) Open the provided Deployment manifest
vi /home/candidate/finer-sunbeam/lamp-deployment.yaml
4) Edit ONLY the Pod template security settings (add/modify these fields) Inside:
spec: -> template: -> spec:
4.1 Set container to run as user 20000
Add (or change) under the container securityContext::
securityContext:
runAsUser: 20000
4.2 Make root filesystem read-only
In the SAME container securityContext: ensure:
readOnlyRootFilesystem: true
4.3 Forbid privilege escalation
In the SAME container securityContext: ensure:
allowPrivilegeEscalation: false
✅ The container section should look like this (example - keep your existing image/ports/etc):
spec:
template:
spec:
containers:
- name: <your-container-name>
image: <unchanged>
securityContext:
runAsUser: 20000
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
If there are multiple containers, apply the same securityContext to each container.
Save and exit:
:wq
5) Apply the manifest (updates Deployment -> recreates Pods)
kubectl -n lamp apply -f /home/candidate/finer-sunbeam/lamp-deployment.yaml
6) Wait for rollout
kubectl -n lamp rollout status deployment/lamp-deployment
7) Verify the security settings are live
7.1 Check the Pod is running
kubectl -n lamp get pods -l app=lamp -o wide
(if label differs, just kubectl -n lamp get pods)
7.2 Verify the three fields on a running Pod
Pick the Pod name and run:
POD=$(kubectl -n lamp get pods -o jsonpath='{.items[0].metadata.name}') kubectl -n lamp get pod $POD -o jsonpath='{.spec.containers[0].securityContext.runAsUser}{"\n"}{.spec.containers[0].securityContext.readOnlyRootFilesystem}{"\n"}{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}' Expected output:
20000
true
false
If the pod fails after readOnlyRootFilesystem=true
Don't change the requirement (task demands it). Usually the app needs writable dirs via volumes, but the task doesn't ask for that-so only adjust if the manifest already has volumes and just needs these securityContext fields.
SIMULATION
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.
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.
正解：
See the Explanation below
Explanation:
Explanation:
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:
SIMULATION
Documentation
ServiceAccount, Deployment,
Projected Volumes
You must connect to the correct host . Failure to do so may
result in a zero score.
[candidate@base] $ ssh cks000033
Context
A security audit has identified a Deployment improperly handling service account tokens, which could lead to security vulnerabilities.
Task
First, modify the existing ServiceAccount stats-monitor-sa in the namespace monitoring to turn off automounting of API credentials.
Next, modify the existing Deployment stats-monitor in the namespace monitoring to inject a ServiceAccount token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
Use a Projected Volume named token to inject the ServiceAccount token and ensure that it is mounted read-only.
The Deployment's manifest file can be found at /home/candidate/stats-monitor/deployment.yaml.
Documentation
ServiceAccount, Deployment,
Projected Volumes
You must connect to the correct host . Failure to do so may
result in a zero score.
[candidate@base] $ ssh cks000033
Context
A security audit has identified a Deployment improperly handling service account tokens, which could lead to security vulnerabilities.
Task
First, modify the existing ServiceAccount stats-monitor-sa in the namespace monitoring to turn off automounting of API credentials.
Next, modify the existing Deployment stats-monitor in the namespace monitoring to inject a ServiceAccount token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
Use a Projected Volume named token to inject the ServiceAccount token and ensure that it is mounted read-only.
The Deployment's manifest file can be found at /home/candidate/stats-monitor/deployment.yaml.
正解：
See the Explanation below for complete solution
Explanation:
1) Connect to correct host
ssh cks000033
sudo -i
export KUBECONFIG=/etc/kubernetes/admin.conf
2) Patch the ServiceAccount to disable automounting
Task: turn off automounting of API credentials for stats-monitor-sa in monitoring.
kubectl -n monitoring patch sa stats-monitor-sa -p '{"automountServiceAccountToken": false}' Verify:
kubectl -n monitoring get sa stats-monitor-sa -o yaml | grep -i automount
3) Edit the Deployment manifest file
Task says to modify the manifest at:
/home/candidate/stats-monitor/deployment.yaml
vi /home/candidate/stats-monitor/deployment.yaml
4) In the Deployment, ensure it uses the ServiceAccount AND inject token via Projected Volume
4.1 Make sure Deployment uses the SA
Under:
spec: -> template: -> spec:
ensure:
serviceAccountName: stats-monitor-sa
(If it already exists, leave it; don't add extra changes beyond requirements.)
4.2 Add a projected volume named token
Under:
spec: -> template: -> spec: -> volumes:
add (or modify existing volume if present) so it is exactly:
- name: token
projected:
sources:
- serviceAccountToken:
path: token
This creates the file token inside the mounted directory, so the final path becomes:
/var/run/secrets/kubernetes.io/serviceaccount/token
4.3 Mount the projected volume read-only at the required location
Under the target container:
spec: -> template: -> spec: -> containers: -> (your container) -> volumeMounts:
Add:
- name: token
mountPath: /var/run/secrets/kubernetes.io/serviceaccount
readOnly: true
✅ This satisfies:
Projected volume name: token
Mount path: /var/run/secrets/kubernetes.io/serviceaccount/token (file inside mount) Mounted read-only
4.4 Important: Don't break default token mount behavior
Because you disabled SA automounting at the ServiceAccount level, you must explicitly mount the projected token (done above). That's the whole point of this task.
Save and exit:
:wq
5) Apply the updated Deployment
kubectl -n monitoring apply -f /home/candidate/stats-monitor/deployment.yaml Wait rollout:
kubectl -n monitoring rollout status deployment/stats-monitor
6) Verify the token file exists in the running Pod
Get a pod name:
POD=$(kubectl -n monitoring get pods -l app=stats-monitor -o jsonpath='{.items[0].metadata.name}') echo $POD Check the token file path exists:
kubectl -n monitoring exec -it $POD -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/token Optional: confirm it's mounted read-only (usually shown by mount options):
kubectl -n monitoring exec -it $POD -- mount | grep /var/run/secrets/kubernetes.io/serviceaccount
✅ What the examiner checks
SA stats-monitor-sa has:
automountServiceAccountToken: false
Deployment stats-monitor mounts a projected volume named token
Token file is at:
/var/run/secrets/kubernetes.io/serviceaccount/token
Mount is readOnly: true
If label selector doesn't match (-l app=stats-monitor)
Use:
kubectl -n monitoring get pods
Then set:
POD=<paste-pod-name>
Explanation:
1) Connect to correct host
ssh cks000033
sudo -i
export KUBECONFIG=/etc/kubernetes/admin.conf
2) Patch the ServiceAccount to disable automounting
Task: turn off automounting of API credentials for stats-monitor-sa in monitoring.
kubectl -n monitoring patch sa stats-monitor-sa -p '{"automountServiceAccountToken": false}' Verify:
kubectl -n monitoring get sa stats-monitor-sa -o yaml | grep -i automount
3) Edit the Deployment manifest file
Task says to modify the manifest at:
/home/candidate/stats-monitor/deployment.yaml
vi /home/candidate/stats-monitor/deployment.yaml
4) In the Deployment, ensure it uses the ServiceAccount AND inject token via Projected Volume
4.1 Make sure Deployment uses the SA
Under:
spec: -> template: -> spec:
ensure:
serviceAccountName: stats-monitor-sa
(If it already exists, leave it; don't add extra changes beyond requirements.)
4.2 Add a projected volume named token
Under:
spec: -> template: -> spec: -> volumes:
add (or modify existing volume if present) so it is exactly:
- name: token
projected:
sources:
- serviceAccountToken:
path: token
This creates the file token inside the mounted directory, so the final path becomes:
/var/run/secrets/kubernetes.io/serviceaccount/token
4.3 Mount the projected volume read-only at the required location
Under the target container:
spec: -> template: -> spec: -> containers: -> (your container) -> volumeMounts:
Add:
- name: token
mountPath: /var/run/secrets/kubernetes.io/serviceaccount
readOnly: true
✅ This satisfies:
Projected volume name: token
Mount path: /var/run/secrets/kubernetes.io/serviceaccount/token (file inside mount) Mounted read-only
4.4 Important: Don't break default token mount behavior
Because you disabled SA automounting at the ServiceAccount level, you must explicitly mount the projected token (done above). That's the whole point of this task.
Save and exit:
:wq
5) Apply the updated Deployment
kubectl -n monitoring apply -f /home/candidate/stats-monitor/deployment.yaml Wait rollout:
kubectl -n monitoring rollout status deployment/stats-monitor
6) Verify the token file exists in the running Pod
Get a pod name:
POD=$(kubectl -n monitoring get pods -l app=stats-monitor -o jsonpath='{.items[0].metadata.name}') echo $POD Check the token file path exists:
kubectl -n monitoring exec -it $POD -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/token Optional: confirm it's mounted read-only (usually shown by mount options):
kubectl -n monitoring exec -it $POD -- mount | grep /var/run/secrets/kubernetes.io/serviceaccount
✅ What the examiner checks
SA stats-monitor-sa has:
automountServiceAccountToken: false
Deployment stats-monitor mounts a projected volume named token
Token file is at:
/var/run/secrets/kubernetes.io/serviceaccount/token
Mount is readOnly: true
If label selector doesn't match (-l app=stats-monitor)
Use:
kubectl -n monitoring get pods
Then set:
POD=<paste-pod-name>
SIMULATION
Using the runtime detection tool Falco, Analyse the container behavior for at least 20 seconds, using filters that detect newly spawning and executing processes in a single container of Nginx.
store the incident file art /opt/falco-incident.txt, containing the detected incidents. one per line, in the format
[timestamp],[uid],[processName]
Using the runtime detection tool Falco, Analyse the container behavior for at least 20 seconds, using filters that detect newly spawning and executing processes in a single container of Nginx.
store the incident file art /opt/falco-incident.txt, containing the detected incidents. one per line, in the format
[timestamp],[uid],[processName]
正解：
Send us your feed back on it
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:- 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
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
正解：
See the Explanation belowExplanation:
Fix all of the following violations that were found against the API server:- a. Ensure that the RotateKubeletServerCertificate argument is set to true.
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
component: kubelet
tier: control-plane
name: kubelet
namespace: kube-system
spec:
containers:
- command:
- kube-controller-manager
+ - --feature-gates=RotateKubeletServerCertificate=true
image: gcr.io/google_containers/kubelet-amd64:v1.6.0
livenessProbe:
failureThreshold: 8
httpGet:
host: 127.0.0.1
path: /healthz
port: 6443
scheme: HTTPS
initialDelaySeconds: 15
timeoutSeconds: 15
name: kubelet
resources:
requests:
cpu: 250m
volumeMounts:
- mountPath: /etc/kubernetes/
name: k8s
readOnly: true
- mountPath: /etc/ssl/certs
name: certs
- mountPath: /etc/pki
name: pki
hostNetwork: true
volumes:
- hostPath:
path: /etc/kubernetes
name: k8s
- hostPath:
path: /etc/ssl/certs
name: certs
- hostPath:
path: /etc/pki
name: pki
b. Ensure that the admission control plugin PodSecurityPolicy is set.
audit: "/bin/ps -ef | grep $apiserverbin | grep -v grep"
tests:
test_items:
- flag: "--enable-admission-plugins"
compare:
op: has
value: "PodSecurityPolicy"
set: true
remediation: |
Follow the documentation and create Pod Security Policy objects as per your environment.
Then, edit the API server pod specification file $apiserverconf
on the master node and set the --enable-admission-plugins parameter to a value that includes PodSecurityPolicy :
--enable-admission-plugins=...,PodSecurityPolicy,...
Then restart the API Server.
scored: true
c. Ensure that the --kubelet-certificate-authority argument is set as appropriate.
audit: "/bin/ps -ef | grep $apiserverbin | grep -v grep"
tests:
test_items:
- flag: "--kubelet-certificate-authority"
set: true
remediation: |
Follow the Kubernetes documentation and setup the TLS connection between the apiserver and kubelets. Then, edit the API server pod specification file
$apiserverconf on the master node and set the --kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>
scored: true
Fix all of the following violations that were found against the ETCD:-
a. Ensure that the --auto-tls argument is not set to true
Edit the etcd pod specification file $etcdconf on the master
node and either remove the --auto-tls parameter or set it to false.
--auto-tls=false
b. Ensure that the --peer-auto-tls argument is not set to true
Edit the etcd pod specification file $etcdconf on the master
node and either remove the --peer-auto-tls parameter or set it to false.
--peer-auto-tls=false
Fix all of the following violations that were found against the API server:- a. Ensure that the RotateKubeletServerCertificate argument is set to true.
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
component: kubelet
tier: control-plane
name: kubelet
namespace: kube-system
spec:
containers:
- command:
- kube-controller-manager
+ - --feature-gates=RotateKubeletServerCertificate=true
image: gcr.io/google_containers/kubelet-amd64:v1.6.0
livenessProbe:
failureThreshold: 8
httpGet:
host: 127.0.0.1
path: /healthz
port: 6443
scheme: HTTPS
initialDelaySeconds: 15
timeoutSeconds: 15
name: kubelet
resources:
requests:
cpu: 250m
volumeMounts:
- mountPath: /etc/kubernetes/
name: k8s
readOnly: true
- mountPath: /etc/ssl/certs
name: certs
- mountPath: /etc/pki
name: pki
hostNetwork: true
volumes:
- hostPath:
path: /etc/kubernetes
name: k8s
- hostPath:
path: /etc/ssl/certs
name: certs
- hostPath:
path: /etc/pki
name: pki
b. Ensure that the admission control plugin PodSecurityPolicy is set.
audit: "/bin/ps -ef | grep $apiserverbin | grep -v grep"
tests:
test_items:
- flag: "--enable-admission-plugins"
compare:
op: has
value: "PodSecurityPolicy"
set: true
remediation: |
Follow the documentation and create Pod Security Policy objects as per your environment.
Then, edit the API server pod specification file $apiserverconf
on the master node and set the --enable-admission-plugins parameter to a value that includes PodSecurityPolicy :
--enable-admission-plugins=...,PodSecurityPolicy,...
Then restart the API Server.
scored: true
c. Ensure that the --kubelet-certificate-authority argument is set as appropriate.
audit: "/bin/ps -ef | grep $apiserverbin | grep -v grep"
tests:
test_items:
- flag: "--kubelet-certificate-authority"
set: true
remediation: |
Follow the Kubernetes documentation and setup the TLS connection between the apiserver and kubelets. Then, edit the API server pod specification file
$apiserverconf on the master node and set the --kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>
scored: true
Fix all of the following violations that were found against the ETCD:-
a. Ensure that the --auto-tls argument is not set to true
Edit the etcd pod specification file $etcdconf on the master
node and either remove the --auto-tls parameter or set it to false.
--auto-tls=false
b. Ensure that the --peer-auto-tls argument is not set to true
Edit the etcd pod specification file $etcdconf on the master
node and either remove the --peer-auto-tls parameter or set it to false.
--peer-auto-tls=false
SIMULATION
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.
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.
正解：
See explanation below
Explanation:
se kubectl to create a CSR and approve it.
Get the list of CSRs:
kubectl get csr
Approve the CSR:
kubectl certificate approve myuser
Get the certificate
Retrieve the certificate from the CSR:
kubectl get csr/myuser -o yaml
here are the role and role-binding to give john permission to create NEW_CRD resource:
kubectl apply -f roleBindingJohn.yaml --as=john
rolebinding.rbac.authorization.k8s.io/john_external-rosource-rb created kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:
name: john_crd
namespace: development-john
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: crd-creation
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: crd-creation
rules:
- apiGroups: ["kubernetes-client.io/v1"]
resources: ["NEW_CRD"]
verbs: ["create, list, get"]
Explanation:
se kubectl to create a CSR and approve it.
Get the list of CSRs:
kubectl get csr
Approve the CSR:
kubectl certificate approve myuser
Get the certificate
Retrieve the certificate from the CSR:
kubectl get csr/myuser -o yaml
here are the role and role-binding to give john permission to create NEW_CRD resource:
kubectl apply -f roleBindingJohn.yaml --as=john
rolebinding.rbac.authorization.k8s.io/john_external-rosource-rb created kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:
name: john_crd
namespace: development-john
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: crd-creation
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: crd-creation
rules:
- apiGroups: ["kubernetes-client.io/v1"]
resources: ["NEW_CRD"]
verbs: ["create, list, get"]