easyMultiple Choice
CKS Practice Question: Is a recommended practice for securing Kubernetes…
Which of the following is a recommended practice for securing Kubernetes Dashboard?
⚠ Common exam trap
Candidates often think exposing the Dashboard via NodePort or LoadBalancer is acceptable for convenience, but the CKS exam emphasizes that any direct network exposure of the Dashboard without strong authentication and TLS is a critical security violation.
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
✓
Deploy Dashboard with minimal RBAC permissions and access it via kubectl proxy.
Deploying the Kubernetes Dashboard with minimal RBAC permissions and accessing it via `kubectl proxy` follows the principle of least privilege and avoids exposing the Dashboard to the network. `kubectl proxy` creates a local HTTP proxy to the Kubernetes API server, which authenticates the user's kubeconfig credentials, ensuring that only authorized users can reach the Dashboard and that the Dashboard itself has no direct network exposure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Deploy Dashboard with minimal RBAC permissions and access it via kubectl proxy.
Why this is correct
Running the Dashboard through kubectl proxy leverages the Kubernetes API server's authentication and authorization, so the Dashboard never binds to a publicly reachable address and all requests are tunneled over the proxy using your kubeconfig credentials. Assigning minimal RBAC permissions, such as a namespace-scoped or read-only role, ensures that even if a session is compromised, the attacker's blast radius is limited to the least privileges required. This combination prevents public exposure and enforces the principle of least privilege without sacrificing usability.
- ✗
Expose Dashboard using a NodePort service with a ClusterRole binding to cluster-admin.
Why it's wrong here
A NodePort service publishes the Dashboard on every node's IP address at a high port, making it directly reachable from the network without going through the API server's authentication layer. Binding the Dashboard to a ClusterRole of cluster-admin gives any user who reaches that port full, unrestricted control over the entire cluster, including creating pods, reading secrets, and deleting namespaces. The Dashboard's own login screen is often skipped or supplies its own service account token, so this configuration effectively hands the cluster to anyone who can access the NodePort, with no per-user audit or authorization.
- ✗
Use a LoadBalancer service without authentication.
Why it's wrong here
Using a LoadBalancer service allocates an external public IP and routes traffic directly to the Dashboard pod, completely bypassing the API server's authentication and authorization mechanisms. Without any additional authentication layer, the Dashboard's UI is available to anyone on the internet; the built-in 'Skip' button on the login page allows unauthenticated users to gain a dashboard session immediately. Since the LoadBalancer also terminates no TLS by default, all management traffic, including any tokens or actions, is transmitted in plaintext, compounding the exposure with credential interception risk.
- ✗
Disable HTTPS and expose Dashboard on port 80.
Why it's wrong here
Disabling HTTPS and exposing the Dashboard on port 80 means all communications between the browser and the Dashboard travel in plaintext, enabling trivial man-in-the-middle attacks to capture authentication tokens, secrets, and Kubernetes management commands. Port 80 is a well-known port that is often allowed through firewalls, but more importantly, this configuration removes the encryption that protects against eavesdropping; even in a trusted network, any network tap or compromised switch can read the traffic. This practice violates basic security standards and is especially dangerous because the Dashboard provides sensitive cluster administration capabilities, so any leaked token or session data can be used for complete cluster compromise.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.