RBAC

Kubernetes Cluster RBAC

Role-Based Access Control (RBAC) is fundamental to securing Kubernetes clusters. It determines who can perform what actions on which resources, ensuring that users and applications have only the permissions they need. In Thalassa Cloud, RBAC operates at multiple levels, providing access control from platform management to in-cluster resource access.

This guide explains how RBAC works in Thalassa Cloud, the different RBAC systems available, and when to use each. Understanding these systems helps you configure secure access control that protects your clusters while enabling your teams to work effectively.

Understanding RBAC in Thalassa Cloud

Thalassa Cloud uses RBAC (role-based access control) at three levels to control access:

Platform IAM – Controls access to Thalassa Cloud itself, such as who can create clusters or access the console. Managed through the Console and API with organisation-level teams and roles.
Kubernetes IAM – Handles permissions for users interacting with your clusters. Assign roles via the Thalassa Cloud Console/API, and the platform creates the needed Kubernetes bindings automatically. Best for managing user access to clusters. More details: Kubernetes IAM documentation.
Kubernetes Native RBAC – The built-in Kubernetes system for controlling access to resources inside your clusters (like pods and deployments), usually used for service accounts or advanced rules.

These layers work together: Platform IAM manages platform access, Kubernetes IAM manages user permissions to clusters, and Native RBAC adds extra control for resources and service accounts inside clusters.

Thalassa Cloud Kubernetes IAM

Thalassa Cloud’s Kubernetes IAM lets you control who can access your clusters from a central place—either in the console or with the API. You can give access to individual users or entire teams at once, and those permissions are set up automatically across all your clusters.

If you add someone to a team, they get the team’s access right away. If you remove them, their access is taken away automatically. This makes it easy to keep permissions up to date as your team changes.

There are built-in roles like cluster-admin (full access) and other levels for different needs. You can also make your own custom roles. For more details, see the Kubernetes IAM documentation and the Cluster Roles documentation.

Kubernetes Native RBAC

Kubernetes has a built-in RBAC system to control who can do what inside a cluster. Thalassa Cloud supports this, so you can use standard Kubernetes RBAC resources.

You mainly use native RBAC for service accounts, in-cluster apps, or when you need more detailed permissions than Kubernetes IAM gives.

There are four main RBAC resources:

Role: Grants permissions in one namespace (for example, to view pods).
ClusterRole: Grants permissions across the whole cluster or to cluster-level resources.
RoleBinding: Gives a Role to a user or service account in a namespace.
ClusterRoleBinding: Gives a ClusterRole to a user or service account cluster-wide.

Define permissions with a Role or ClusterRole, then link them to users or service accounts with a RoleBinding or ClusterRoleBinding.

Example: Creating a Role and RoleBinding

The following example demonstrates how to create a namespace-scoped role that grants read-only access to pods. This is useful for users who need to monitor applications but shouldn’t be able to modify them.

First, create a Role that defines the permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

This Role grants permission to get and list pods in the default namespace. The apiGroups: [""] refers to the core API group, and resources: ["pods"] specifies pods as the resource. The verbs field defines what actions are allowed—in this case, reading pod information.

Next, create a RoleBinding that grants this role to a user:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: pod-reader-binding
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This RoleBinding connects the pod-reader role to the user alice. The subjects section specifies who receives the permissions, and the roleRef section specifies which role is being granted.

Apply both resources to the cluster:

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

After applying these resources, the user alice can view pods in the default namespace but cannot create, modify, or delete them. This demonstrates how Kubernetes Native RBAC provides fine-grained control over permissions.

Choosing the Right RBAC System

Thalassa Cloud provides multiple RBAC systems, and choosing the right one for each use case ensures effective access control. Understanding when to use each system helps you configure permissions appropriately.

Use Kubernetes IAM For

Kubernetes IAM should be used for managing human users and external systems that interact with Kubernetes clusters through the Thalassa Cloud API or Console. This includes developers who need to deploy and manage applications, administrators who manage cluster configuration, and third-party integrations using Thalassa Cloud Personal Access Tokens.
Kubernetes IAM is ideal when you want centralized management of access across multiple clusters. Since it’s managed at the platform level, you configure access once and it applies everywhere. This is especially valuable when running multiple clusters, as you don’t need to configure access separately for each cluster.
Use Kubernetes IAM when you want team-based access control. The integration with Thalassa Cloud’s team system makes it easy to manage permissions for groups of users, and team membership automatically determines access. This simplifies management and ensures consistency.

Use Kubernetes Native RBAC For

Kubernetes Native RBAC should be used for resources within the cluster, particularly service accounts that applications use to interact with the Kubernetes API. Service accounts are Kubernetes resources that represent identities for workloads running in the cluster, and they need RBAC permissions to access other resources.
Use Kubernetes Native RBAC when you need fine-grained control over specific resources or namespaces that goes beyond what Kubernetes IAM provides. For example, you might use native RBAC to grant a service account permission to read secrets in a specific namespace, or to allow a CI/CD system’s service account to deploy applications.
Kubernetes Native RBAC is also useful when you need to define permissions that are specific to a single cluster and don’t need to be consistent across all clusters. Since native RBAC is managed per-cluster, you can customize it for cluster-specific requirements.

Integration and Coordination

Kubernetes IAM and Kubernetes Native RBAC operate at different levels and can be used together without conflict. Kubernetes IAM manages permissions for human users—such as developers and administrators—while Kubernetes Native RBAC is focused on service accounts and access control for workloads running inside the cluster.

In practice, when a user connects to the cluster, their access is determined by IAM settings. When an application or service account interacts with the cluster, its permissions are set by Native RBAC rules. Using both systems allows you to centrally manage user access and set fine-grained permissions for applications and workloads within each cluster.