Secrets Manager

Thalassa Cloud Secrets Manager

Thalassa Cloud Secrets Manager is a regional, path-based secret store for sensitive values such as database credentials, API keys, and certificates. It follows a model similar to AWS Secrets Manager or Scaleway Secrets Manager: the path is the identity of a secret, values are versioned, and every version is encrypted with a customer-chosen KMS key in the same region.

Secrets Manager is a consumer of Key Management Service (KMS). You need KMS enabled and at least one operational symmetric encryption key in the target region before you can store secrets.

Availability

Your organisation must have both feature gates enabled:

Feature gate	If disabled
`secrets`	All Secrets Manager API calls return `403 Forbidden`
`kms`	All calls return `403` with a message that KMS must be enabled first

The target region must have a configured, enabled KMS endpoint. If KMS is not available in the region, crypto operations return 503 Service Unavailable.

Dependency chain

  → secrets feature gate enabled
    → kms feature gate enabled
      → regional KMS endpoint available
        → symmetric KMS key created and active
          → secret can be created and used

What you can do with Secrets Manager

Capability	Description
Store secrets by path	Hierarchical paths such as `/app/production/db/password` uniquely identify secrets
Version values	Each update creates a new revision; read or destroy older versions independently
Reveal values	Decrypt and return secret material via `getSecretValue`
Browse by path	File-browser style listing or flat recursive search under a prefix
Path-scoped IAM	Fine-grained access per path (for example, `/app/prod/` but not `/app/staging/`)
Access policies	Optional IP and time-of-day rules on top of IAM for reveal and write operations

Core concepts

Concept	Description
Secret	A container identified by its path, scoped to organisation, region, and optionally project
Version	A numbered revision (1, 2, 3, …) holding one value; the latest active version is marked `current`
KMS binding	Each secret is bound to exactly one symmetric KMS key at creation; the binding is immutable
Value formats	Single string, key/value map, or platform-generated random bytes

Secret values are never returned on list or metadata APIs. Use getSecretValue to reveal a decrypted value.

Documentation

Guides

Step-by-step tutorials for common workflows

Getting started

Prerequisites, create a KMS key, store your first secret

Creating secrets

String, key/value, and generate modes

Reading and updating

Reveal values and add new versions

Version management

Current version, history, and destroy

Access policies

IP and time-of-day restrictions

Reference

Concepts

Paths, versions, formats, and envelope encryption

Paths and naming

Path rules, hierarchy, browse vs flat list

Access control

IAM roles and path-scoped permissions

KMS integration

Key binding, supported types, key state impact

Audit log

Logged operations and dual KMS entries

Billing

Stored versions and get-value calls

Best practices

Security guidance for production

API reference

Endpoints and request requirements

Secret lifecycle overview

Create secret (version 1)
    │
    ├─ PutSecretValue → version 2, 3, … (current moves forward)
    │
    ├─ GetSecretValue → read current or historical version
    │
    ├─ DestroySecretVersion → version N marked destroyed (unreadable)
    │
    └─ DeleteSecret → secret and all versions removed

See Version management for details on each operation.