Access control

KMS access control (IAM)

Access to KMS keys is controlled through Thalassa Cloud IAM. The resource type for KMS is kms_key.

IAM policies

Thalassa Cloud provides built-in KMS policies including kms:ReadAccess, kms:FullAccess, and single-action policies such as kms:Encrypt and kms:Decrypt. See the KMS default policies catalogue for the full list.

Assign policies through organisation roles or project IAM policies, consistent with other Thalassa Cloud resources.

Permission mapping

Action	Permission
List keys, get key, export public key	`list`, `read`
Create key, get BYOK wrapping key	`create`
Encrypt, decrypt, sign, verify, HMAC, rotate, export key material	`update`
Disable, enable, delete, cancel deletion	`delete`

Recommended policy assignment

Persona	Policy	Rationale
Key administrators	`kms:FullAccess`	Create, rotate, and decommission keys
Compliance and security reviewers	`kms:ReadAccess`	Inspect metadata and versions without crypto or lifecycle access
Application service accounts	Custom role	Crypto operations without create, delete, or export

Follow least privilege: applications that only encrypt and decrypt should not receive kms:FullAccess. Create a custom role with the minimum permissions required—for example, read, list, and update for encrypt and decrypt only.

Project scoping

KMS keys can be organisation-scoped or project-scoped:

Organisation-scoped keys — Managed without a project context; visible when no project identity is provided
Project-scoped keys — Created and accessed with X-Project-Identity or an OIDC project claim

IAM policy bindings can be attached at organisation or project level. A principal with project-level access on project A cannot access project B’s keys. See IAM policies and KMS default policies.

List and get operations return only keys in the active scope.

Access denied behaviour

Users without permission to access a key receive 404 Not Found, not 403 Forbidden. This prevents leaking whether a key exists.

Ensure your automation handles 404 as a potential permissions issue, not only a missing resource.

Custom roles

For workloads that need crypto without full administrative access, create custom roles with specific permission combinations on kms_key. For example, a role that allows encrypt and decrypt but not export or delete:

read, list — Discover keys
update — Encrypt, decrypt, sign, or verify as required

Omit create and delete for application service accounts. Omit export-related update scope unless break-glass access is explicitly required.

See RBAC roles and permissions for creating custom roles and role bindings.

Service accounts

Use custom roles for application service accounts that perform crypto operations. Reserve kms:FullAccess for key administrators. Rotate service account credentials on your standard schedule and bind policies at project scope where possible.

See Service accounts.