正解：

See the Explanation below for complete solution
Explanation:
1) SSH to control-plane node
ssh cks000002
sudo -i
2) Edit API Server static pod manifest
API server in kubeadm runs as a static pod.
vi /etc/kubernetes/manifests/kube-apiserver.yaml
3) Apply required API Server security settings
3.1 Forbid anonymous authentication
Find command: section and ensure this line exists:
- --anonymous-auth=false
3.2 Use authorization mode Node,RBAC
Ensure exactly this line exists (and no AlwaysAllow):
- --authorization-mode=Node,RBAC
❌ Remove if present:
- --authorization-mode=AlwaysAllow
3.3 Enable admission controller NodeRestriction
Find --enable-admission-plugins and ensure NodeRestriction is included.
Correct example:
- --enable-admission-plugins=NodeRestriction
If other plugins already exist, append NodeRestriction, e.g.:
- --enable-admission-plugins=NamespaceLifecycle,ServiceAccount,NodeRestriction
4) Save file and let kubelet restart API server
Just save and exit (:wq)
Kubelet will automatically restart the API server pod.
5) Switch kubectl to secured config
Current kubectl will stop working after API server hardening.
export KUBECONFIG=/etc/kubernetes/admin.conf
Verify access:
kubectl get nodes
6) Remove insecure ClusterRoleBinding
Delete system:anonymous binding:
kubectl delete clusterrolebinding system:anonymous
Verify removal:
kubectl get clusterrolebinding | grep anonymous
(no output = correct)
7) Quick validation (optional but fast)
API server flags check:
grep -n "anonymous-auth" /etc/kubernetes/manifests/kube-apiserver.yaml
grep -n "authorization-mode" /etc/kubernetes/manifests/kube-apiserver.yaml grep -n "NodeRestriction" /etc/kubernetes/manifests/kube-apiserver.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

正解：

See the Explanation belowExplanation:

正解：

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