CKS Practice Question: Which TWO of the following are recommended…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Avoid exposing the dashboard to the public internet

  Why this is correct

  Exposing the Kubernetes Dashboard to the public internet is dangerous because it is a highly privileged web interface that often operates with administrative service account tokens. Even with authentication enabled, public exposure expands the attack surface, allowing attackers to attempt credential brute-force, exploit known CVEs, or abuse misconfigured authorization rules, potentially leading to full cluster takeover. The dashboard should be accessed only through trusted channels such as `kubectl proxy`, an SSH tunnel, or a strictly controlled internal network with TLS encryption and strong identity verification.

• ✗

  Expose the dashboard via a NodePort service for easy access

  Why it's wrong here

  Using a NodePort service to expose the dashboard is unsafe because it publishes the dashboard on every node's IP address on a high port (30000–32767) within the cluster's node network. This bypasses typical ingress security controls, service meshes, and firewalls, making the dashboard directly reachable from any network that can access the nodes—often without TLS termination, audit logging, or robust authentication enforcement. Attackers can easily discover such exposed ports via network scanning, turning a convenience feature into an inadvertent public endpoint. Instead, operators should rely on `kubectl proxy`, which binds to localhost and automatically applies API server authentication and authorization.

• ✗

  Enable anonymous access to the dashboard

  Why it's wrong here

  Enabling anonymous access on the Kubernetes Dashboard effectively removes the requirement for any credentials, allowing anyone who can reach the dashboard to interact with cluster resources if the anonymous Kubernetes user has been granted RBAC permissions. While anonymous access might seem convenient for initial setup or demos, it violates the principle of least privilege and can lead to unauthorized modifications, data exfiltration, or privilege escalation if the dashboard is reachable outside the cluster. Even within a trusted network, a compromised browser or a malicious internal user could abuse this access. The dashboard should always require explicit authentication via service account tokens, `kubeconfig` files, or an identity-aware proxy.

• ✓

  Use RBAC to restrict dashboard permissions

  Why this is correct

  Applying RBAC (Role-Based Access Control) to the Kubernetes Dashboard is a critical security best practice because it limits what the dashboard's service account or user can do within the cluster. By creating fine-grained Roles or ClusterRoles that only allow necessary API operations (e.g., `get`, `list`, `watch` on specific resources in designated namespaces), you reduce the blast radius in case the dashboard is compromised. Granting cluster-admin to the dashboard is a common misconfiguration that turns it into a weapon for complete cluster control; a least-privileged setup ensures that even an attacker who gains dashboard access cannot delete nodes, modify secrets, or create privileged pods. RBAC works in conjunction with authentication to enforce the principle of least privilege in every Kubernetes API call.

• ✗

  Run the dashboard as a DaemonSet

  Why it's wrong here

  Running the Kubernetes Dashboard as a DaemonSet is not a security best practice and does not improve the component's security posture. In fact, a DaemonSet would schedule a dashboard pod on every node in the cluster, increasing the number of running instances that need to be patched, monitored, and protected—thereby expanding the attack surface and resource usage. Security for the dashboard is determined by its network exposure, authentication mechanisms, RBAC permissions, and the underlying container image's vulnerability posture, not by its deployment topology. The standard approach of running a single Deployment with a Service (or no external service at all) is sufficient for managing the dashboard, while a DaemonSet adds unnecessary complexity and provides no tangible security benefit.

Go deeper

Related to this question