mediumMultiple Select
CKS Practice Question: Which TWO of the following are best practices for…
Which TWO of the following are best practices for hardening Kubernetes Dashboard?
⚠ Common exam trap
CNCF often tests the misconception that 'more permissions make the Dashboard work better' or that 'HTTP is simpler and acceptable for internal use,' but the correct approach is to always enforce TLS and minimal RBAC, as the exam expects you to prioritize security over convenience.
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
✓
Grant minimal RBAC permissions to Dashboard service account
The Kubernetes Dashboard should run with the least privilege necessary. Granting minimal RBAC permissions to the Dashboard's service account follows the principle of least privilege, reducing the attack surface if the Dashboard is compromised. The default installation often creates a service account with excessive permissions, which should be scoped down to only what the Dashboard needs to function.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Grant minimal RBAC permissions to Dashboard service account
Why this is correct
Granting minimal RBAC permissions to the dashboard service account enforces the principle of least privilege. Instead of a cluster-admin binding, create a dedicated Role and RoleBinding that only allows read-only access to specific resources, like pods and logs, within a single namespace. This limits the blast radius if the dashboard or its service account token is compromised, preventing an attacker from deleting or modifying cluster-wide resources.
- ✓
Do not expose Dashboard via a public LoadBalancer Service
Why this is correct
Exposing the Dashboard through a public LoadBalancer service opens the Kubernetes control plane UI to the internet, bypassing boundary security. The Dashboard should be accessed internally via `kubectl proxy`, which creates an authenticated localhost tunnel, or restricted through an allowlisted ingress controller with TLS. Public exposure invites brute-force credentials attacks and exploits of any dashboard API endpoint, so it must be avoided.
- ✗
Use HTTP to avoid certificate management
Why it's wrong here
Using HTTP for the Dashboard transmits bearer tokens, API requests, and user credentials as plaintext across the network, making them trivial to intercept with packet capture or man-in-the-middle attacks. Additionally, lacking TLS eliminates server identity verification, enabling a malicious party to masquerade as the Dashboard. Certificate management should be solved with reliable provisioning, such as cert-manager, rather than sacrificing transport security.
- ✗
Use the default service account with cluster-admin binding
Why it's wrong here
Attaching the default service account to a cluster-admin binding grants every pod and component that reuse that account unrestricted control over the entire Kubernetes cluster. This violates least privilege and means any compromised container can immediately read secrets, delete workloads, or create privileged pods. It also undermines auditability because actions are attributed to a generic shared identity, making it impossible to trace malicious activity to a specific application.
- ✗
Enable anonymous access for simplicity
Why it's wrong here
Enabling anonymous access to the Dashboard disables authentication, allowing any unauthenticated user to query the API and view cluster information, and depending on RBAC, modify resources. This creates a severe security hole because the Dashboard becomes a public attack surface with no identity, no authorization checks, and no audit trail for forensics. Kubernetes should always require explicit authentication for all interactions, leaving anonymous access disabled except for deliberately isolated health endpoints.
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
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 →
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.