hardMultiple Select
CKS Practice Question: Which THREE of the following are recommended…
Which THREE of the following are recommended practices for securing Kubernetes Dashboard?
⚠ Common exam trap
CNCF often tests the principle of least privilege by presenting options that seem convenient (like full admin access or NodePort exposure) but violate security best practices, and the trap here is that candidates may think exposing the Dashboard via NodePort is acceptable for internal access, ignoring that it bypasses authentication layers and network segmentation.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Disable anonymous access to Dashboard
The Kubernetes Dashboard, by default, may allow unauthenticated access if not explicitly configured. Disabling anonymous access ensures that all requests to the Dashboard are authenticated, preventing unauthorized users from viewing or manipulating cluster resources. This is typically done by setting the `--enable-skip-login` flag to false or configuring the Dashboard deployment to require authentication tokens.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Disable anonymous access to Dashboard
Why this is correct
The Dashboard's bundled v1.7 and earlier manifests historically bound the service account to cluster-admin and permitted unauthenticated access, which lets anyone who can reach the Dashboard URL control the cluster. Disabling anonymous access forces every request through Kubernetes authentication, ensuring the Dashboard's TLS endpoint rejects unauthenticated users before any API action is attempted. This directly closes the known CVE-2018-18264 vector where anonymous users could leverage Dashboard's service account to execute commands in pods.
- ✗
Expose Dashboard via NodePort service on all nodes
Why it's wrong here
Exposing Dashboard via a NodePort service binds a high port on every cluster node's external interface, making the UI reachable from any network path that can route to those node IPs. NodePort services have no built-in authentication or network policy enforcement and often bypass cloud load balancer or ingress access controls, so an attacker who discovers the port gains a direct attack surface to the Dashboard's login and API proxy. Recommended alternatives are kubectl port-forward for admin access, or an internal Ingress with mTLS, SSO, and network policy restrictions.
- ✓
Use RBAC to grant Dashboard service account only necessary permissions
Why this is correct
The Dashboard's service account should be bound only to roles that the UI's features actually require, such as read-only access to namespaced resources for viewing workloads, or narrowly scoped verbs like get, list, and watch for the namespaces the operator manages. Granting a broad, permissive role defeats RBAC's purpose and increases the blast radius if the Dashboard pod or its bearer token is compromised. Least privilege means no cluster-admin binding and no wildcard resources or verbs unless the deployment explicitly requires them and is protected by strong network controls.
- ✓
Avoid exposing Dashboard over the public internet
Why this is correct
Exposing Dashboard over the public internet makes it reachable from anywhere on the internet, amplifying brute-force and credential-stuffing attacks on its login endpoint, and any authentication bypass or token leakage becomes remotely exploitable. Even with HTTPS and RBAC, public exposure relies entirely on the UI's login flow and the security of user credentials, whereas a private network placement or kubectl port-forward restricts access to authenticated users on known hosts. Public exposure also increases the risk of cross-site request forgery and malicious redirects, so it should be avoided in favor of VPN, bastion, or service mesh authorization.
- ✗
Create a ClusterRole with full cluster admin access for Dashboard
Why it's wrong here
Creating a ClusterRole with full cluster admin access for Dashboard would grant the Dashboard's service account permissions to create pods, read secrets, modify RBAC, and delete cluster-scoped resources, far exceeding what the UI needs for read-only monitoring or troubleshooting. Such a role effectively hands any Dashboard user or XSS vector the power to take over the entire cluster, because the Dashboard acts as a proxy using its own service account identity. The correct approach is to bind the Dashboard to granular roles—both namespaced and cluster-scoped—limited to the specific verbs and resources required by the operator.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are recommended practices for securing the Kubernetes Dashboard? (Select TWO)
medium- A.Use HTTP instead of HTTPS for Dashboard traffic
- B.Disable authentication for the Dashboard
- ✓ C.Restrict Dashboard access using RBAC with minimal privileges
- D.Use the default cluster-admin ServiceAccount for Dashboard access
- ✓ E.Avoid exposing the Dashboard on a public IP address
Why C: The Kubernetes Dashboard should be secured using Role-Based Access Control (RBAC) with minimal privileges. This follows the principle of least privilege, ensuring that users or service accounts accessing the Dashboard have only the permissions necessary for their tasks, reducing the attack surface and potential blast radius in case of compromise.
Variation 2. Which TWO of the following are recommended practices for securing the Kubernetes dashboard?
medium- ✓ A.Avoid exposing the dashboard to the public internet
- B.Expose the dashboard via a NodePort service for easy access
- C.Enable anonymous access to the dashboard
- ✓ D.Use RBAC to restrict dashboard permissions
- E.Run the dashboard as a DaemonSet
Why A: Exposing the Kubernetes dashboard to the public internet significantly increases the attack surface, making it a prime target for credential theft, API abuse, and cluster compromise. The dashboard should only be accessible via internal networks, VPNs, or using kubectl proxy with authentication, never directly over the internet.
Variation 3. Which TWO practices help secure the Kubernetes Dashboard?
hard- A.Enable anonymous access to the Dashboard
- ✓ B.Use a ClusterIP service and access it via kubectl proxy
- C.Grant the Dashboard service account cluster-admin role for full functionality
- ✓ D.Use RBAC to restrict Dashboard service account permissions to read-only
- E.Expose the Dashboard via a NodePort service for easy access
Why B: Accessing the Kubernetes Dashboard via `kubectl proxy` creates a secure, authenticated HTTP proxy between your local machine and the API server. This method leverages the API server's built-in authentication and authorization, ensuring that only users with valid kubeconfig credentials can reach the Dashboard. It also avoids exposing the Dashboard directly to the network, reducing the attack surface.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.