RBAC Roles and Permissions

Overview

Role-Based Access Control (RBAC) in Thalassa Cloud lets you control who can do what in your organisation. RBAC uses roles and permissions to manage access. You can define what actions users, teams, and service accounts can perform on specific resources.

RBAC helps you follow the principle of least privilege. This means you only give people the access they need to do their work. This improves security and makes it easier to manage access.

How RBAC Works

RBAC uses three main concepts: roles, permissions, and role bindings. Roles are collections of permissions. Permissions define what actions can be performed. Role bindings connect roles to users, teams, or service accounts.

Think of it like this: a role is a job description that lists what someone can do. A role binding assigns that job to a specific person or team. Permissions are the individual tasks that make up the job.

RBAC Components

Roles

Roles are collections of permissions. You can create roles that define what actions someone can take. Roles can be assigned to organisation members, teams, or service accounts.

Thalassa Cloud provides predefined roles for common use cases. These are ready-to-use templates that cover typical scenarios. You can also create custom roles with specific permission combinations that match your needs.

When you create a role, you define permissions at the resource level. For example, you might create a role that allows read access to Kubernetes clusters but write access only to specific namespaces. This gives you fine-grained control over what people can do.

Permissions

Permissions define specific actions that can be performed on resources. Common permissions include:

• Create: Create new resources
• Read/List: View and list resources
• Update: Modify existing resources
• Delete: Remove resources

Permissions are always tied to a specific resource type. For example, you might have permissions for Kubernetes clusters, VPCs, or service accounts. Each resource type has its own set of permissions.

Role Bindings

Role bindings connect roles to subjects. A subject can be an organisation member, a team, or a service account. When you create a role binding, you’re saying “this role applies to this person or team.”

Role bindings also define the scope of access. You can limit a role binding to specific resources or set time limits. This lets you grant temporary access or restrict access to certain parts of your infrastructure.

For example, you might create a role binding that gives a developer read access to all Kubernetes clusters, but only write access to clusters in the development environment. This gives them the access they need without exposing production resources.

Creating Custom Roles

Custom roles let you create exactly the permissions you need. This is useful when predefined roles don’t match your requirements. You can combine permissions in any way that makes sense for your organisation.

Step 1: Role Definition

Role Binding Management

Role bindings connect roles to subjects. You can create role bindings in two ways: from the subject’s page or from the role’s page. Both methods achieve the same result.

Creating Role Bindings from a Subject

This is useful when you want to assign roles to a specific user or team.

Creating Role Bindings from a Role

This is useful when you want to assign a role to multiple subjects.

Understanding Permissions

Permissions control what actions can be performed on resources. Each permission allows a specific type of action:

• Create: Allows creating new resources
• Read/List: Allows viewing and listing resources
• Update: Allows modifying existing resources
• Delete: Allows removing resources

Permissions are scoped to resource types. For example, you might have permissions for Kubernetes clusters, VPCs, load balancers, or other resources. When you assign permissions, you specify both the resource type and the allowed actions.

Best Practices

• Follow the principle of least privilege. Only grant the minimum permissions needed for someone to do their job. This reduces security risk and makes it easier to understand who has access to what.
• Use descriptive names for roles. Names like kubernetes-read-only or vpc-admin make it clear what the role does. This helps others understand when to use each role.
• Review role bindings regularly. Check if they’re still needed and if the permissions are still appropriate. Remove bindings that are no longer needed to keep your access control clean.
• Document your roles. Add clear descriptions that explain when and why to use each role. This helps team members understand the access control structure.
• Define custom roles and permissions in code, for example through Terraform.

Related Documentation

• Service Accounts: Learn about service accounts and how to use them with RBAC
• Managing Teams: Organise users into teams for easier role binding
• Workload Identity Federation: Use OIDC for service account impersonation