Description
Kubernetes Dashboard provides web-based cluster management, but its authentication, permissions and network access require ongoing care. Its presence alone does not mean internet exposure. Retaining an unnecessary deployment creates more opportunities for access-control mistakes and missed patches.
Potential impact
- Authentication or permission mistakes can expose excessive management functions.
- Unused components still require patching and maintenance.
Remediation
- If Dashboard is not needed, identify and remove its deployment and dedicated access paths and permissions. Check for resources shared with other workloads first.
- If it is needed, maintain a supported deployment and apply strong authentication, least privilege and network restrictions. Verify who can actually reach it and through which paths.
Examples
The first example is a Deployment excerpt with a historical Dashboard image, not a complete deployment. The second Secret is a separate resource; applying it does not remove an existing Dashboard.
Before
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: kubernetes-dashboard
namespace: kube-system
spec:
template:
spec:
containers:
- name: kubernetes-dashboard
image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
A historical Dashboard container is defined. External reachability depends on its Service and network configuration.
After
yaml
apiVersion: v1
kind: Secret
metadata:
name: application-secret
namespace: kube-system
type: Opaque
This only defines an ordinary Secret. Removing Dashboard requires separate cleanup of the actual deployment and related resources.