Cluster Hardening
Cluster hardening centers on least-privilege access to the API server and safe service account usage. Know RBAC deeply: Roles are namespaced while ClusterRoles are cluster-scoped; a RoleBinding can reference a ClusterRole but grants it only inside its own namespace, whereas a ClusterRoleBinding grants cluster-wide. Verbs are case-sensitive and include get, list, watch, create, update, patch, delete, and deletecollection. Avoid wildcards and never bind to system:masters. Use resourceNames to narrow access to specific objects.
Service accounts deserve special attention. Set automountServiceAccountToken: false at the Pod or ServiceAccount level unless the workload calls the API, and prefer short-lived projected tokens over long-lived Secret-based tokens. Disable anonymous authentication on the kubelet and API server, and restrict kubelet access with proper authorization. Traps: binding a ClusterRole with a RoleBinding and expecting cluster-wide power; forgetting a subject can be a ServiceAccount identified by namespace and name; and assuming the absence of a Secret token prevents all API access.
Rule of thumb: every ServiceAccount should be able to do only what its workload needs, and if the workload never calls the API it should receive no token at all.
Worked example: to let a CI service account read Pods in namespace ci only, create a Role granting get/list/watch on pods, then a RoleBinding in ci with subject kind ServiceAccount, name ci-sa, namespace ci.