Skip to content

Kubernetes Updated 2026-05-27

Kubernetes access control

How RBAC works on a Stack Harbor PaaS Kubernetes cluster, the default cluster-admin token, and the right way to share cluster access with other users.

A Stack Harbor PaaS Kubernetes cluster manages authorization through Kubernetes-native RBAC — Role, ClusterRole, RoleBinding, and ClusterRoleBinding resources tied to ServiceAccount subjects. The cluster ships with one bootstrap token whose ServiceAccount carries the cluster-admin role; everything else is on you to define.

This page is the short version of what to do with that initial admin token and how to grant scoped access to teammates without handing out cluster-admin.

The default token

After cluster installation, the dashboard surfaces an access token. That token is bound to a ServiceAccount with the cluster-admin ClusterRoleBinding — it can do anything on the cluster. Treat it like a root credential:

  • Keep it out of source control.
  • Use it for bootstrap and admin tooling, not for application workloads.
  • Rotate it if you suspect exposure (delete the Secret, the controller regenerates).

For day-to-day work, especially in a team setting, the cluster-admin token is the wrong tool. Mint scoped ServiceAccounts instead.

Sharing cluster access — the right shape

The pattern that holds up in practice:

  1. Create a dedicated ServiceAccount per human or per automation that needs access. One account per purpose makes audit trails legible.
  2. Define a Role or ClusterRole that lists exactly the verbs and resources that account needs. Start tight (get, list, watch on pods) and broaden as you discover real needs.
  3. Bind them with RoleBinding (namespace-scoped) or ClusterRoleBinding (cluster-wide).
  4. Hand out the ServiceAccount token to the user or paste it into their CI pipeline.

A first-cut split:

  • Read-only observability — get, list, watch on pods, services, deployments, ingresses, events. Useful for developers who need to debug their service without being able to change cluster state.
  • Namespace owner — full verbs scoped to a single namespace. Lets a team manage their own application without seeing the rest of the cluster.
  • Cluster operator — full cluster verbs except for managing RBAC itself, reserved for the people who run the cluster.
  • Cluster admin — the bootstrap token. Used by no one, in practice, except for the one-off operations that can’t be done without it.

Two caveats specific to Stack Harbor

  • Kubernetes RBAC is not the same surface as platform accounts. Sharing a Kubernetes environment through the platform’s standard sharing feature exposes SSH access to the master node — and the master node has a pre-configured kubectl with the cluster-admin role. In effect, anyone you share the environment with through the platform can act as cluster-admin regardless of what RBAC says. Share with that in mind, and rotate the master node’s kubectl configuration if you need to revoke access.
  • The platform firewall doesn’t constrain Kubernetes. Network rules inside the cluster are managed dynamically by Kubernetes (via the CNI plugin, NetworkPolicy, and the ingress controller). The dashboard’s firewall settings don’t apply to in-cluster traffic. If you need network policy, define NetworkPolicy resources.

See also