Introduction

If you want an HTTPS connection to Kubernetes Dashboard, the first thing to know is that the current Dashboard deployment already expects secure access through its proxy service. The second thing to know is more important in 2026: Kubernetes documentation now marks Dashboard as deprecated and unmaintained, so exposing it publicly should be a deliberate, temporary choice rather than a default admin pattern.

Start With the Current Deployment Model

Current Dashboard installation guidance uses Helm and exposes the UI through the kubernetes-dashboard-kong-proxy service. A local secure access path looks like this:

1helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
2helm upgrade --install kubernetes-dashboard \
3  kubernetes-dashboard/kubernetes-dashboard \
4  --create-namespace \
5  --namespace kubernetes-dashboard
6
7kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443

After that, you reach the UI at:

https://localhost:8443

For many teams, that is the safest answer. Traffic is protected with TLS, access stays local to the machine running kubectl, and you avoid publishing the dashboard on the internet.

External HTTPS Usually Belongs at an Ingress

If you really need remote browser access, do not patch random old manifest snippets that mount ad hoc cert files into outdated dashboard containers. The modern pattern is to keep the dashboard service internal and terminate TLS at an ingress controller or load balancer.

Example ingress:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: kubernetes-dashboard
5  namespace: kubernetes-dashboard
6spec:
7  ingressClassName: nginx
8  tls:
9    - hosts:
10        - dashboard.example.com
11      secretName: dashboard-tls
12  rules:
13    - host: dashboard.example.com
14      http:
15        paths:
16          - path: /
17            pathType: Prefix
18            backend:
19              service:
20                name: kubernetes-dashboard-kong-proxy
21                port:
22                  number: 443

The TLS secret referenced above must already exist:

kubectl -n kubernetes-dashboard create secret tls dashboard-tls \
  --cert=dashboard.crt \
  --key=dashboard.key

This approach keeps certificate management in the normal Kubernetes ingress layer instead of hiding one-off TLS wiring inside the dashboard pod spec.

Use a Valid Certificate for the Public Hostname

If users browse to https://dashboard.example.com, the certificate must match that hostname. A self-signed certificate may work for internal testing, but browsers will warn unless the issuing certificate authority is trusted by the client machine.

In production-like environments, people often use:

• a certificate issued by their internal PKI
• cert-manager with an internal or public issuer
• a cloud load balancer with managed certificates

The exact certificate source matters less than the rule: the TLS endpoint presented to the browser must match the name the browser is using.

Authentication Still Matters After TLS

TLS protects transport. It does not replace dashboard login and cluster authorization. Current guidance still expects token-based login rather than assuming a browser certificate or kubeconfig-based workflow will solve everything automatically.

That means an HTTPS URL alone is not a complete security story. You still need:

• a controlled login process
• minimal RBAC permissions
• network restrictions
• an access path you are willing to expose

Why Port-Forward Is Often Better

Administrative UIs are attractive targets. When possible, use:

kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443

This gives you encrypted local access without publishing an externally reachable admin surface. For many operations teams, that is a better tradeoff than maintaining a permanently exposed dashboard hostname.

Consider Not Using Dashboard at All

Because the official Kubernetes docs now describe Dashboard as deprecated and unmaintained, a new deployment should be evaluated carefully. If you are designing a fresh operational workflow, consider alternatives instead of investing heavily in a permanent Dashboard exposure model.

That does not make current deployments unusable, but it should change how much infrastructure you build around them.

Common Pitfalls

The most common mistake is following old blog posts that assume manifest-based installation and older service names. Current Dashboard installation is Helm-based and sits behind the Kong proxy service.

Another issue is confusing TLS with overall security. HTTPS protects the connection, but it does not automatically solve authentication, authorization, or network exposure. Teams also often publish the dashboard publicly when a local kubectl port-forward session would have been sufficient.

Summary

• Current Dashboard access is already HTTPS-oriented through the kubernetes-dashboard-kong-proxy service.
• The safest common option is local secure access through kubectl port-forward.
• If you need remote access, terminate TLS at an ingress or load balancer with a real certificate.
• Do not rely on outdated manifest-based TLS tutorials for current Dashboard installs.
• Kubernetes Dashboard is deprecated and unmaintained, so avoid treating it as a long-term public admin surface.