Documentation
Kubernetes
IAM

Kubernetes IAM

Thalassa Cloud provides a centralized way to manage who can access your Kubernetes clusters and what actions they can perform, using its Kubernetes IAM system. This system integrates tightly with Kubernetes RBAC, so you can assign roles to users and teams at the platform level, and Thalassa Cloud takes care of creating or updating the necessary RBAC bindings in every cluster.

What Is Kubernetes IAM?

Kubernetes IAM lets you define access rules once—using your Thalassa Cloud teams and roles—and have those rules applied automatically to all Kubernetes clusters you operate. Rather than configuring access in each cluster, you use a single interface to grant or revoke cluster permissions.

Behind the scenes, Thalassa Cloud converts these permissions into Kubernetes RBAC rules like Roles and RoleBindings or ClusterRoles and ClusterRoleBindings. This reduces manual work and ensures your access rules are kept in sync everywhere.

How Access Control Works: Three Layers

There are three main layers for controlling access:

  • Platform IAM: Controls what users can do in the Thalassa Cloud console or API, including creating clusters and managing infrastructure.
  • Kubernetes IAM: Lets you assign cluster access (like admin or read-only) to users and teams. This is set at the platform level and automatically applied to all clusters.
  • Kubernetes RBAC: The native access control system inside every cluster. Thalassa Cloud creates and manages the RBAC rules for users based on your IAM assignments. For details about RBAC itself and how it works, see the RBAC documentation.

You can also manually manage advanced RBAC rules inside clusters if needed.

Centralized, Team-Based Permissions

With Kubernetes IAM, you organise users into teams and assign cluster-level roles to those teams. For example, you might have a “dev-team” with read/write access and a “ops-team” with admin access. All team members get the assigned permissions automatically, and when teams change (users join or leave), permissions update everywhere.

Individual user assignments are also supported for special cases, but teams are preferred—they scale better and are easier to manage.

Getting Started

  1. Check your access: You’ll need platform permissions to manage Kubernetes IAM (usually admin).
  2. Review cluster roles: Use built-in roles like cluster-admin, or define custom roles as needed.
  3. Organise users into teams: Structure teams to match your organisation. For help, see the teams guide.
  4. Assign roles: In the Thalassa Cloud console’s IAM section (under Kubernetes), assign the right roles to teams or users.
  5. Verify access: Have users connect and verify they can do what you expect.

For more on how RBAC works and what roles do, refer to the RBAC documentation.

Verifying and Troubleshooting Access

When users report access issues, systematic troubleshooting helps identify the problem. Start by verifying that the user is a member of the team that has the Kubernetes role assigned. Check the team membership in the IAM section of the console.

Next, verify that the role binding exists and is correctly configured. In the Kubernetes IAM section, check that the team has the expected role assigned. If the binding looks correct, verify that it has been applied to the clusters. You can check this by connecting to a cluster and viewing the ClusterRoleBindings:

kubectl get clusterrolebindings

This shows all cluster role bindings in the cluster. Look for bindings that reference your teams or users. The bindings created by Kubernetes IAM typically have names that reflect the platform-level configuration.

If bindings exist but access still isn’t working, check the user’s authentication. Ensure they’re using the correct credentials and that their identity is being recognized by the cluster. You can verify this by checking who the cluster thinks the user is:

kubectl auth can-i get pods --as=user@example.com

This command tests whether a specific user can perform an action. Replace the user identity with the actual user’s identity as recognized by the cluster.

Common issues include users not being members of the expected teams, role bindings not being created correctly, or authentication problems. The centralized nature of Kubernetes IAM means that fixing issues at the platform level should resolve them across all clusters.

Integration with Platform IAM

Kubernetes IAM and Platform IAM do different things. Platform IAM controls access to Thalassa Cloud itself—like managing clusters, infrastructure, and using the console or API. Kubernetes IAM controls what users can do inside the clusters—such as managing pods, deployments, or services.

  • Most users need permissions at both levels: Platform IAM to use the console and manage clusters, and Kubernetes IAM to work with cluster resources.
  • You might have some users who only need to manage clusters (Platform IAM) and others who only need to deploy and manage apps inside clusters (Kubernetes IAM).

Further Reading

To deepen your understanding of Kubernetes access control and Thalassa Cloud IAM, explore the following resources:

  • Cluster Roles documentation: Details on available cluster roles and steps for creating custom roles and role bindings for your clusters.
  • IAM documentation: Information about managing users, teams, and permissions at the platform level in Thalassa Cloud.
  • Kubernetes RBAC documentation: Learn about the in-cluster Kubernetes RBAC system, use cases for service accounts, and how it integrates with Thalassa Cloud’s access controls.