Access Control

Kubernetes Cluster: Access Control

Kubernetes controls access through RBAC (Role-Based Access Control). By default, cluster access is provided through a ServiceAccount token associated with the cluster-admin role. For shared access, create separate ServiceAccounts and grant only the permissions each user actually requires.
RBAC Controls which Kubernetes actions a user or ServiceAccount is allowed to perform.
ServiceAccount Provides an identity that can be assigned Kubernetes permissions and used for authenticated access.
Role / ClusterRole Defines the operations that are permitted on Kubernetes resources.
RoleBinding / ClusterRoleBinding Connects a user or ServiceAccount to the permissions defined by a role.
On this page

Default Cluster Access

The Kubernetes cluster uses RBAC to authorize operations. The default cluster access token belongs to a ServiceAccount that has the cluster-admin role.

Full administrative access: A token associated with cluster-admin can manage the entire Kubernetes cluster. Treat this credential as highly sensitive.

Share Cluster Access Safely

Do not share the default cluster-admin token when another person needs only limited access. Instead, create a dedicated ServiceAccount for that user or integration.

  • Create a separate ServiceAccount.
  • Create or select the required Role or ClusterRole.
  • Bind that role to the ServiceAccount using a RoleBinding or ClusterRoleBinding.
  • Share only the credentials associated with that limited account.
This approach makes permissions easier to review, change, and revoke without affecting other users or administrators.

Control Allowed Actions

RBAC permissions can be tailored to the tasks a user must perform. For example, access can be designed to allow only selected operations such as:

Namespaces Allow a user to create, view, or manage namespaces where required.
Deployments Grant permission to create or update application deployments.
Services Permit creation or management of Kubernetes Service objects.
Ingresses Allow selected users to configure ingress resources without granting full cluster administration.
Least-privilege principle: Grant only the permissions required for the user’s role. Avoid cluster-admin access for routine application-management tasks.

Master Node SSH Access

Kubernetes RBAC permissions are separate from platform account permissions. A user who receives SSH access to a Kubernetes master node can use the preconfigured kubectl client, which has cluster-admin capabilities.

Environment sharing warning: Sharing the Kubernetes environment through the platform can expose sensitive cluster information if the recipient receives SSH access to a master node. Review platform sharing permissions carefully before granting access.

For users who require limited Kubernetes privileges, providing a dedicated RBAC-controlled ServiceAccount is safer than granting master-node SSH access.

Platform Firewall Limitation

The standard platform firewall feature does not manage Kubernetes Cluster rules. Kubernetes dynamically manages the networking and firewall rules required by cluster services and workloads.

Plan Kubernetes network restrictions through Kubernetes-native networking, ingress, service, and policy mechanisms rather than relying on the standard platform container firewall feature.
Access-control summary: Keep the default cluster-admin credential private, use separate ServiceAccounts for shared access, apply RBAC with least privilege, and avoid giving master-node SSH access to users who do not require full cluster administration.

What’s next?