Lesson 0022 · 45 minutes · Cluster Hardening

Remove weak API-server access paths

The API server is the cluster’s security boundary. A permissive flag can bypass all the careful RBAC and workload policy built above it, so secure the control-plane configuration first.

Timed task: 35 minutes

Review lab/lesson-22-kube-apiserver-insecure.yaml. Create lab/lesson-22-kube-apiserver-answer.yaml as a complete replacement static-Pod manifest.

Preserve the API version, kind, Pod name, namespace, host networking, container name, image, --etcd-servers, and --service-cluster-ip-range. Harden the API server so it:

• Rejects anonymous API requests.
• Uses Node,RBAC authorization rather than AlwaysAllow.
• Validates ServiceAccount tokens against the API server.
• Disables profiling endpoints.
• Writes audit events to /var/log/kubernetes/audit/audit.log instead of standard output.

Do not add a new API server, change the image, or use an API object such as a Deployment. This is a static control-plane Pod manifest. It must not be applied to the Kind lab.

Verification

Get-Content .\lab\lesson-22-kube-apiserver-answer.yaml

# On a real kubeadm control-plane node, inspect the active static Pod:
sudo grep -E -- '--anonymous-auth|--authorization-mode|--service-account-lookup|--profiling|--audit-log-path' /etc/kubernetes/manifests/kube-apiserver.yaml

Production changes to the API-server manifest require the approved control-plane maintenance process. A kubelet automatically restarts its static Pod when the manifest changes, so do not make experimental edits on a live production control plane.

Retrieval check

Documentation target

Use the Kubernetes kube-apiserver command reference to confirm the security-flag behavior.

What to send me

Paste your complete command list. I’ll review one flag at a time and preserve your request not to reveal the next correction early.