IAM policies
Thalassa Cloud IAM policies let you define project-scoped access control: who can do what, on which resources, within a specific project. Built-in policies ship with the platform and use the same permission rules as organisation roles.
We are transitioning towards projects and project-scoped IAM policies as the primary way to manage access. Organisation roles are not being removed — existing organisation-wide role bindings continue to work. During the transition you can use both models side by side.
For new workloads we recommend modelling access with IAM policies inside projects rather than organisation roles alone.
Projects and IAM policies require the
projectsfeature gate on your organisation.
IAM policies are included with the platform at no extra charge. Projects, built-in system policies, custom policies, and policy bindings are not metered or billed.
Getting started
Scopes
| Scope | What it is | Where it applies |
|---|---|---|
| Organisation role | Org-wide RBAC binding (legacy, still supported) | Every API call in the organisation |
| IAM policy | Project-scoped RBAC binding (recommended) | API calls made with an active project context |
Default IAM policies reuse the same permission rules as organisation roles. A principal’s effective permissions are the union of all organisation role bindings and all IAM policy bindings that apply to the active project context.
When you create a project, the platform provisions default system IAM policies automatically and binds the creator to the admin policy.
Related documentation
- Projects — Logical groupings and project hierarchy
- RBAC roles — Organisation-wide roles
- Service accounts — Principals for policy bindings