Linux Foundation CKS 問題集

質問 1：
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.
正解：
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


質問 2：
SIMULATION
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 number of 8 old audit logs files are retained.
4. set the maximum size before getting rotated to 200MB
Edit and extend the basic policy to log:
1. namespaces changes at RequestResponse
2. Log the request body of secrets changes in the namespace kube-system.
3. Log all other resources in core and extensions at the Request level.
4. Log "pods/portforward", "services/proxy" at Metadata level.
5. Omit the Stage RequestReceived All other requests at the Metadata level
正解：
Kubernetes auditing provides a security-relevant chronological set of records about a cluster. Kube-apiserver performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what's recorded and the backends persist the records.
You might want to configure the audit log as part of compliance with the CIS (Center for Internet Security) Kubernetes Benchmark controls.
The audit log can be enabled by default using the following configuration in cluster.yml:
services:
kube-api:
audit_log:
enabled: true
When the audit log is enabled, you should be able to see the default values at /etc/kubernetes/audit-policy.yaml The log backend writes audit events to a file in JSONlines format. You can configure the log audit backend using the following kube-apiserver flags:
--audit-log-path specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend. - means standard out
--audit-log-maxage defined the maximum number of days to retain old audit log files
--audit-log-maxbackup defines the maximum number of audit log files to retain
--audit-log-maxsize defines the maximum size in megabytes of the audit log file before it gets rotated If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the hostPath to the location of the policy file and log file, so that audit records are persisted. For example:
--audit-policy-file=/etc/kubernetes/audit-policy.yaml \
--audit-log-path=/var/log/audit.log

質問 3：
SIMULATION

Context
The kubeadm-created cluster's Kubernetes API server was, for testing purposes, temporarily configured to allow unauthenticated and unauthorized access granting the anonymous user duster-admin access.
Task
Reconfigure the cluster's Kubernetes API server to ensure that only authenticated and authorized REST requests are allowed.
Use authorization mode Node,RBAC and admission controller NodeRestriction.
Cleaning up, remove the ClusterRoleBinding for user system:anonymous.


正解：
See the Explanation below
Explanation:






質問 4：
SIMULATION
Context
You must implement auditing for the kubeadm provisioned cluster.
Task
First, reconfigure the cluster 's API server, so that:
. the basic audit policy located at
/etc/kubernetes/logpolicy/audit-policy.yaml is used,
. logs are stored at /var/log/kubernetes/audit-logs.txt,
. and a maximum of 2 logs are retained for 10 days.
The cluster uses the Docker Engine as its container runtime . If needed, use the docker command to troubleshoot running containers.
The basic policy only specifies what not to log.
Next, edit and extend the basic policy to log:
. namespaces interactions at RequestResponse level
. the request body of deployments interactions in the namespace webapps
. ConfigMap and Secret interactions in all namespaces at the Metadata level
. all other requests at the Metadata level
Make sure the API server uses the extended policy.
Failure to do so may result in a reduced score.
正解：
See the Explanation below for complete solution
Explanation:
1) Connect to the correct host
ssh cks000028
sudo -i
(If hostname differs in your exam, use the one shown in the question banner.)
2) Edit the API server static pod manifest
API server is a static pod in kubeadm.
vi /etc/kubernetes/manifests/kube-apiserver.yaml
3) Configure API server to enable auditing
Inside the command: section, ensure ALL of the following flags exist
(add them if missing, modify if present).
3.1 Use the given audit policy file
- --audit-policy-file=/etc/kubernetes/logpolicy/audit-policy.yaml
3.2 Store audit logs at the required location
- --audit-log-path=/var/log/kubernetes/audit-logs.txt
3.3 Retain a maximum of 2 log files
- --audit-log-maxbackup=2
3.4 Retain logs for 10 days
- --audit-log-maxage=10
✅ Example (your file may have more flags - that's fine):
- command:
- kube-apiserver
- --audit-policy-file=/etc/kubernetes/logpolicy/audit-policy.yaml
- --audit-log-path=/var/log/kubernetes/audit-logs.txt
- --audit-log-maxbackup=2
- --audit-log-maxage=10
Save and exit:
:wq
The API server will auto-restart (static pod).
Optional quick check:
docker ps | grep kube-apiserver
4) Edit and EXTEND the audit policy
Open the given basic policy:
vi /etc/kubernetes/logpolicy/audit-policy.yaml
The file already contains rules for what NOT to log.
You must ADD rules BELOW them (do not delete existing ones).
5) Add the required audit rules (EXACT ORDER)
Append the following rules in this order (order matters in audit policies).
5.1 Log namespaces interactions at RequestResponse
- level: RequestResponse
resources:
- group: ""
resources: ["namespaces"]
5.2 Log deployment request bodies in namespace webapps
- level: RequestResponse
namespaces: ["webapps"]
resources:
- group: "apps"
resources: ["deployments"]
5.3 Log ConfigMap and Secret interactions (all namespaces) at Metadata
- level: Metadata
resources:
- group: ""
resources: ["configmaps", "secrets"]
5.4 Log all other requests at Metadata
This must be LAST
- level: Metadata
5.5 Final audit-policy.yaml should END like this
# (existing "do not log" rules above)
- level: RequestResponse
resources:
- group: ""
resources: ["namespaces"]
- level: RequestResponse
namespaces: ["webapps"]
resources:
- group: "apps"
resources: ["deployments"]
- level: Metadata
resources:
- group: ""
resources: ["configmaps", "secrets"]
- level: Metadata
Save and exit:
:wq
6) Make sure API server uses the EXTENDED policy
Touch the manifest to guarantee reload:
touch /etc/kubernetes/manifests/kube-apiserver.yaml
Wait a few seconds.
7) Verify auditing is working
7.1 Check audit log file exists
ls -l /var/log/kubernetes/audit-logs.txt
7.2 Generate test activity
kubectl get namespaces
kubectl get configmaps -A
7.3 Confirm logs are written
tail -n 20 /var/log/kubernetes/audit-logs.txt
You should see audit entries.

質問 5：
SIMULATION
Secrets stored in the etcd is not secure at rest, you can use the etcdctl command utility to find the secret value for e.g:- ETCDCTL_API=3 etcdctl get /registry/secrets/default/cks-secret --cacert="ca.crt" --cert="server.crt" --key="server.key" Output

Using the Encryption Configuration, Create the manifest, which secures the resource secrets using the provider AES-CBC and identity, to encrypt the secret-data at rest and ensure all secrets are encrypted with the new configuration.
正解：
See the Explanation belowExplanation:
ETCD secret encryption can be verified with the help of etcdctl command line utility.
ETCD secrets are stored at the path /registry/secrets/$namespace/$secret on the master node.
The below command can be used to verify if the particular ETCD secret is encrypted or not.
# ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C

質問 6：
SIMULATION
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context dev
Context:
A CIS Benchmark tool was run against the kubeadm created cluster and found multiple issues that must be addressed.
Task:
Fix all issues via configuration and restart the affected components to ensure the new settings take effect.
Fix all of the following violations that were found against the API server:
1.2.7 authorization-mode argument is not set to AlwaysAllow FAIL
1.2.8 authorization-mode argument includes Node FAIL
1.2.7 authorization-mode argument includes RBAC FAIL
Fix all of the following violations that were found against the Kubelet:
4.2.1 Ensure that the anonymous-auth argument is set to false FAIL
4.2.2 authorization-mode argument is not set to AlwaysAllow FAIL (Use Webhook autumn/authz where possible) Fix all of the following violations that were found against etcd:
2.2 Ensure that the client-cert-auth argument is set to true
正解：
See the Explanation below
Explanation:
worker1 $ vim /var/lib/kubelet/config.yaml
anonymous:
enabled: true #Delete this
enabled: false #Replace by this
authorization:
mode: AlwaysAllow #Delete this
mode: Webhook #Replace by this
worker1 $ systemctl restart kubelet. # To reload kubelet config
ssh to master1
master1 $ vim /etc/kubernetes/manifests/kube-apiserver.yaml
- -- authorization-mode=Node,RBAC
master1 $ vim /etc/kubernetes/manifests/etcd.yaml
- --client-cert-auth=true
Explanation:
ssh to worker1
worker1 $ vim /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: true #Delete this
enabled: false #Replace by this
webhook:
cacheTTL: 0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
mode: AlwaysAllow #Delete this
mode: Webhook #Replace by this
webhook:
cacheAuthorizedTTL: 0s
cacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
resolvConf: /run/systemd/resolve/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
worker1 $ systemctl restart kubelet. # To reload kubelet config
ssh to master1
master1 $ vim /etc/kubernetes/manifests/kube-apiserver.yaml

master1 $ vim /etc/kubernetes/manifests/etcd.yaml


質問 7：
SIMULATION
Documentation
Deployment, Pod Security Admission, Pod Security Standards
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000036
Context
For compliance, all user namespaces enforce the restricted Pod Security Standard .
Task
The confidential namespace contains a Deployment that is not compliant with the restricted Pod Security Standard . Thus, its Pods can not be scheduled.
Modify the Deployment to be compliant and verify that the Pods are running.
The Deployment's manifest file can be found at /home/candidate/nginx-unprivileged.yaml.
正解：
See the Explanation below for complete solution
Explanation:
1) Connect to the correct host
ssh cks000036
sudo -i
export KUBECONFIG=/etc/kubernetes/admin.conf
2) Confirm the failing Pods + see the PSA error (fast)
kubectl -n confidential get deploy
kubectl -n confidential get pods
kubectl -n confidential describe deploy <deployment-name> | sed -n '/Events/,$p' (You'll usually see "violates PodSecurity 'restricted' ..." with the exact missing fields.)
3) Edit the provided manifest
vi /home/candidate/nginx-unprivileged.yaml
You must ensure the Pod template becomes compliant. Add/ensure the following exact blocks:
4) Add Pod-level securityContext (under spec.template.spec)
Find:
spec:
template:
spec:
Add this block under it (or merge if securityContext: already exists):
securityContext:
runAsNonRoot: true
runAsUser: 65535
seccompProfile:
type: RuntimeDefault
5) Add Container-level securityContext (under the nginx container)
Find:
containers:
- name: ...
image: ...
Under that container, add (or adjust) this exact block:
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
If there are multiple containers, apply the same container securityContext to each one.
Save and exit:
:wq
6) Apply the manifest to the confidential namespace
kubectl -n confidential apply -f /home/candidate/nginx-unprivileged.yaml Wait rollout:
kubectl -n confidential rollout status deployment/<deployment-name>
If you don't know the deployment name from the file, list:
kubectl -n confidential get deploy
7) Verify Pods are running
kubectl -n confidential get pods -o wide
If still failing, show the exact PSA violation (this tells you what else to fix):
kubectl -n confidential describe pod <pod-name> | sed -n '/Events/,$p'
Quick "if it still fails" fixes (common restricted blockers)
Open the manifest again and ensure these are NOT set (or are removed/false):
hostNetwork: true
hostPID: true
hostIPC: true
any hostPort:
privileged: true
capabilities.add:
seccompProfile: Unconfined
runAsUser: 0 or runAsNonRoot: false
Then re-apply.
Minimal compliant result (what the grader expects)
Your Pod template should include:
seccompProfile: RuntimeDefault
runAsNonRoot: true (and a non-root UID like 65535)
container: allowPrivilegeEscalation: false
container: capabilities.drop: [ALL]
container: readOnlyRootFilesystem: true