Access control

Secrets Manager access control (IAM)

Access to secrets is controlled through Thalassa Cloud IAM. The resource type is secret and the resource identity is the full path string (for example, /app/production/db/password).

Built-in policies

Policy	Permissions	Typical use
`secrets:ReadAccess`	`read`, `list`	View metadata and version history; cannot reveal values
`secrets:FullAccess`	`create`, `read`, `update`, `delete`, `list`, `getSecretValue`, `putSecretValue`	Full lifecycle including reveal and write

See Secrets Manager default policies for slug and binding details.

Empty resourceIdentities in a role rule means all paths in scope (organisation or project).

Permission reference

Permission	Operations
`create`	Create secret at path
`read`	Get secret metadata; browse/list filtering
`list`	List/browse operation (still filtered per-path by `read`)
`update`	Set or clear access policy
`putSecretValue`	Add new version
`getSecretValue`	Decrypt and reveal value
`delete`	Delete secret; destroy version

Path-scoped IAM policies

Bind roles or IAM policies on resource secret with resourceIdentities set to specific paths. This enables fine-grained access patterns:

Team	Policy example
Ops team	Full access to `/infra/*`
App team	`getSecretValue` on `/app/production/*` only
Auditors	`read` on all paths, no `getSecretValue`

List filtering

Even with list permission, browse and flat list results only include paths where the caller also has read. Revealing values requires explicit getSecretValue on each path.

Create check

Creating a secret at a path requires create permission on that exact path.

Recommended policy assignment

Persona	Role	Rationale
Secret administrators	`secrets:FullAccess`	Create, rotate, and decommission secrets
Compliance and security reviewers	`secrets:ReadAccess`	Inspect metadata and version history without reveal access
Application service accounts	Custom role	`getSecretValue` only on required paths

Follow least privilege: grant getSecretValue only to principals that need runtime access. Use secrets:ReadAccess for auditors who only need metadata.

Project scoping

Secrets can be organisation-scoped or project-scoped:

Organisation-scoped secrets — Managed without a project context; visible when no project identity is provided
Project-scoped secrets — 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 secrets. See IAM policies and secrets:ReadAccess / secrets:FullAccess for project-scoped access control.

List, get, and mutations only apply within the active scope.

KMS permissions

Secrets Manager encrypts and decrypts values using the bound KMS key. Principals performing getSecretValue or putSecretValue need permissions on both:

The secret path (via getSecretValue or putSecretValue)
The bound KMS key (for underlying encrypt/decrypt)

Ensure service accounts have KMS crypto permissions on the keys bound to secrets they access.

Custom roles

For workloads that need reveal without administrative access, create custom roles with specific permission combinations on secret. For example, a CI service account that reads one production secret:

read, list — Discover secrets (filtered to permitted paths)
getSecretValue — Reveal values at /app/production/deploy-token only

Omit create, delete, and putSecretValue unless the principal manages secret lifecycle.

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

Service accounts

Use custom roles for application and CI service accounts. Reserve secrets:FullAccess for secret administrators. Bind policies at project scope where possible and limit getSecretValue to specific paths.

See Service accounts.