Skip to content

Kubernetes Updated 2026-05-27

Kubernetes cluster access

Two paths into a freshly installed Stack Harbor PaaS Kubernetes cluster — the Kubernetes Dashboard and the kubectl client over Remote API.

A Stack Harbor PaaS Kubernetes cluster comes up with two equivalent management surfaces: the Kubernetes Dashboard (a web UI accessible from the post-install pop-up) and the kubectl command-line client (pre-installed on every master node, and connectable from a local workstation through the Remote API).

This page covers both paths — when to use each, and where to find the access credentials.

Kubernetes Dashboard

The dashboard is the fastest way to verify the cluster is healthy after install and to browse running workloads. It’s not a replacement for kubectl for serious operations — most cluster management is faster from the command line — but it’s a useful first stop.

  1. After the cluster installs, the platform’s success pop-up surfaces the dashboard URL and the bootstrap access token. The same information is also emailed to the account owner.
  2. Open the URL.
  3. Select Token as the authentication method and paste the value.

The dashboard can also accept a kubeconfig file instead of a raw token, but that path requires installing kubectl locally and configuring the right context — at which point you might as well use kubectl directly. The token path is the quickest.

Recover a lost dashboard token

If you’ve lost the post-install email, the bootstrap token is recoverable from the master node. Open Web SSH on the master and run:

kubectl -n kube-system describe secret \
  $(kubectl -n kube-system get secret | grep fulladmin | awk '{print $1}') \
  | grep 'token:' | sed -e 's/token:\|//g' | tr -d ' '

The output is the token — paste it into the dashboard. (If the cluster was provisioned in restricted mode or with a custom RBAC layout, the secret name may not be fulladmin; adapt the grep accordingly.)

kubectl on the master node

kubectl is installed on every master node during cluster provisioning, with the right kubeconfig already in place. To use it, open Web SSH on a master and run commands directly — no setup required:

kubectl get nodes
kubectl get pods --all-namespaces

This is the easiest path for a quick check, and it’s also the only path where the in-built cluster-admin role works without explicit token handling.

kubectl from a local workstation

For real ongoing work, install kubectl on your workstation and configure it to talk to the cluster’s Remote API endpoint:

kubectl config set-cluster stackharbor --server={api-endpoint} && \
kubectl config set-context stackharbor --cluster=stackharbor && \
kubectl config set-credentials user --token={token} && \
kubectl config set-context stackharbor --user=user && \
kubectl config use-context stackharbor

Replace:

  • {api-endpoint} with the Remote API URL surfaced in the post-install pop-up.
  • {token} with the access token (same value used for the dashboard).

Verify the connection:

kubectl get pods

You should see pods in the default namespace. If the call returns an authentication error, the token is wrong; if it times out, the Remote API isn’t reachable from your network — check the API endpoint URL and any firewall in front of your workstation.

Enable Remote API after install

If Remote API access wasn’t selected at install time, you can add it later. Open the master layer’s Add-Ons panel and install the Remote API add-on. The add-on surfaces the new endpoint URL once it’s ready.

See also