Public API Server, cluster-admin Binding, and Disabled Audit Logs
A self-managed Kubernetes 1.28 cluster has three control-plane nodes and 150 workers. The API server sits behind an L4 load balancer with a public IP so remote engineers can use kubectl. During an audit you find: --anonymous-auth=true on the API server; a ClusterRoleBinding gives system:authenticated the built-in cluster-admin role; audit logging is disabled; etcd data is not encrypted at rest; kubelets still expose read-only port 10255; and control-plane certificates were issued manually for five years. The security team wants to close the public endpoint immediately, but remote engineers and a third-party monitoring vendor depend on it. The cluster runs production payments and internal HR workloads. Leadership asks for a risk-ordered remediation plan that avoids an outage and explains what an attacker could do today.
1. Rank the first three remediation actions by risk and justify the order.
Read the worked answer
First, remove the ClusterRoleBinding to system:authenticated. It turns any valid token, including a low-privilege service-account token, into cluster-admin and makes every other control secondary.
Second, restrict the API endpoint to authorized networks or a VPN/bastion. Public exposure expands the attacker pool and enables credential stuffing and token replay.
Third, enable audit logging to a central immutable backend and rotate the five-year control-plane certificates and any exposed tokens. Audit logging is needed to see whether the other issues have already been exploited; certificate rotation limits long-term persistence.
I would put etcd encryption and closing kubelet port 10255 next. They matter, but an attacker with cluster-admin can read secrets through the API, so encryption at rest alone does not stop them. The order reflects exploitability and blast radius, not checklist order.
2. Describe a plausible attack path from a leaked low-privilege service-account token to production data, and identify where each control failure helps the attacker.
Read the worked answer
A leaked token from a CI log or a compromised low-privilege pod is used against the public API. Because system:authenticated has cluster-admin, the token immediately lists all Secrets, including payments and HR.
The attacker creates a pod with a hostPath mount or reads other service-account tokens through the API, then reaches node credentials or the container runtime. Disabled audit logging removes the record. Unencrypted etcd makes disk or backup theft easier. Open kubelet read-only port 10255 exposes pod and log data without authentication. Long-lived certificates let the attacker persist.
Each failure is not independent: the authorization bug converts a minor token leak into cluster takeover, and the public endpoint makes the token usable from anywhere. The likely first observable would be a burst of API list calls, but without audit logs that signal is lost.
3. Design a safe replacement for the public API endpoint for remote engineers and the monitoring vendor without an outage.
Read the worked answer
Move the endpoint to a private load balancer reachable only through VPN or a bastion with SSO and MFA. If the vendor needs access, use a narrowly scoped, reviewed path such as a dedicated namespace with a vendor service account and IP allowlisting. Add OIDC with short-lived credentials and remove static kubeconfigs.
Phase it: first publish the private endpoint and test from VPN, then update DNS and firewall rules, then disable the public endpoint after a rollback window. Keep audit logs and alert on API calls from new ASNs.
For the monitoring vendor, prefer a pull-based agent in-cluster or a vendor relay with least privilege rather than broad API access. The goal is not just hiding the endpoint; it is reducing credential value and making access auditable. A hard cutover without a tested private path would create an outage and pressure teams to reopen the public endpoint.