Platform security

This page describes how Thalassa Cloud secures the platform we operate — the controls, principles, and engineering practices behind our Public Cloud infrastructure.

Customer-facing security configuration — IAM policies, VPC firewalling, Kubernetes hardening, and secrets management — is documented separately. See Related documentation at the end of this page.

Security on Thalassa Cloud follows the shared responsibility model. We secure the platform; you secure what you deploy and configure on it. If you plan penetration tests or disaster recovery exercises on your workloads, see Security assessments.

Security principles

These principles apply across the control plane, data plane, build systems, and operational tooling that make up the Thalassa Cloud platform.

Supply chain integrity

We treat software supply chain security as a first-class requirement. Every container image and artefact that runs on the platform is signed with Cosign before it is promoted to production.

This gives us cryptographic assurance that what runs in production is exactly what our pipelines produced, not a substituted or modified image.

Least privilege

Access within the platform follows least-privilege by default — for both human operators and automated systems.

• Role separation — Engineering, operations, and security functions use distinct roles with narrowly scoped permissions. Elevated access is time-bound and auditable.
• Service accounts — Platform components authenticate as dedicated service accounts with permissions limited to their specific function. Broad, shared credentials are not used.
• Project and organisation scope — Customer-facing IAM mirrors this model: resources and policies are scoped to organisations and projects so blast radius stays contained. See IAM policies.
• Break-glass only — Emergency access exists but is exceptional, logged, and reviewed.

No principal — human or machine — receives more authority than its task requires.

Authentication always

Unauthenticated access to platform services is not permitted. Every request to the control plane, internal APIs, and operational tooling must present valid credentials.

There is no implicit trust based on network location alone. Being inside a VPC or data center network does not bypass authentication.

Identity over static secrets

Long-lived static secrets — API keys, shared passwords, and embedded tokens — are an anti-pattern on Thalassa Cloud. We apply this principle internally across every platform service and component, and we actively encourage customers to adopt the same approach for their workloads and integrations.

Internally, service-to-service communication, CI/CD pipelines, infrastructure automation, and operator tooling all authenticate through federated identity, dedicated service accounts, or short-lived tokens. Static credentials are not shared between components and are not embedded in configuration.

For customers, we provide first-class primitives to follow the same model:

Workload Identity Federation is the recommended authentication path for CI/CD pipelines, Terraform, and third-party integrations — for our platform and for yours. Where a static token cannot yet be replaced, it is treated as a tracked exception: narrowly scoped, rotated on schedule, and removed as soon as a federated alternative is available.

Network exposure and segmentation

We expose as little as possible to the public internet. Platform services are designed to be reachable only where external access is genuinely required.

  Internet
      │
      ▼
  ┌─────────────┐     ┌──────────────────────────────────┐
  │  Edge / LB  │────▶│  Customer-facing APIs (auth req.) │
  └─────────────┘     └──────────────────────────────────┘
                              │
                              ▼
                    ┌──────────────────┐
                    │  Control plane   │  ◀── not publicly routable
                    │  (private nets)  │
                    └──────────────────┘
                              │
                    ┌──────────────────┐
                    │  Data plane      │  ◀── tenant-isolated VPCs
                    │  (per-customer)  │
                    └──────────────────┘

• Default deny — Firewall rules and security groups follow a default-deny posture. Traffic is permitted only by explicit rule.
• Private control plane — Internal platform services communicate over private networks. Management interfaces are not exposed on public IPs.
• Customer isolation — VPCs, security groups, and firewall rules give customers the same segmentation primitives to keep workloads off the public internet. Kubernetes clusters support VPC-only API access.
• Egress control — Outbound traffic from platform components is restricted to known destinations where policy requires it.

Capacity management

Availability is a security concern. Degraded or exhausted capacity can amplify the impact of abuse, misconfiguration, or targeted disruption. We manage platform capacity proactively so services remain responsive under normal growth and under stress.

Capacity management works alongside the denial-of-service mitigations in our threat models — rate limiting, redundancy, and monitoring form a layered defence against availability incidents.

Automation, testing, and change control

Manual changes to production infrastructure are avoided. Platform changes flow through automated pipelines that are tested in non-production environments first.

• Infrastructure as Code — Platform and customer-facing infrastructure is defined in code (Terraform, Pulumi) and applied through pipelines, not by hand.
• Regression testing — Automated test suites validate API behaviour, networking, storage, and service integrations on every change.
• Reproducibility — Staging environments mirror production topology so failures surface before they reach customers.
• Change records — Deployments are tied to source revisions, giving a complete audit trail from commit to running system.

This reduces the risk of configuration drift, human error, and untracked changes in production.

Code scanning and review

All platform code passes through review and automated analysis before merge.

Threat modeling

Every platform service undergoes structured threat modeling before production release and is reassessed when architecture or exposure changes materially.

We use a STRIDE-based approach — identifying threats across Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege — mapped to concrete mitigations and residual risk acceptance.

Example threat matrix

The table below illustrates the threat categories we assess for each service. Each production service has its own documented matrix with service-specific threats, mitigations, and owners.

Threat models are living documents. They are updated when new attack surfaces are introduced — for example, a new API endpoint, a changed network path, or an additional third-party integration.

Backup and data retention

Backup scope on Thalassa Cloud follows the shared responsibility model. We back up the platform services required to operate the cloud; you are responsible for backing up your workload data unless you arrange additional services with us.

Platform services

We always back up the data stores and configuration required to run Thalassa Cloud itself. This includes — but is not limited to — the cloud platform API databases, KMS metadata, the identity provider (IDP), and any other internal service on which our managed offerings depend.

These backups exist to restore Thalassa Cloud platform services. They do not contain your workload data (only it’s metadata and desired state).

Customer data

We do not back up customer data storage by default. Services that hold your data — block storage volumes, object storage, snapshots, and similar resources — are your responsibility to protect.

Instead of platform-managed backups, customer storage services include safeguards against accidental loss:

You are responsible for creating off-site backups of your workloads if your compliance or disaster recovery requirements demand them. Use snapshots, object storage replication, application-level backup tools, or DBaaS backup features as appropriate for your architecture.

If you need additional backup services beyond the platform defaults — for example, managed off-site backup of block storage or object storage — contact Thalassa Cloud support to discuss options.

Compliance and data protection

ISO/IEC 27001

Thalassa Cloud operates its information security management system (ISMS) in accordance with ISO/IEC 27001. Our policies, risk assessments, access controls, change management, and incident response procedures follow the standard — we work to it day to day, not only at audit time.

We are in the final stages of formal ISO/IEC 27001 certification, with the external audit approaching completion. Until the certificate is issued, treat our ISMS as operating to ISO/IEC 27001 requirements rather than as a completed certification.

Data center and workload standards

All infrastructure is hosted in the Netherlands within the European Union. Data is encrypted at rest and in transit. Platform operations are logged for compliance investigation.

For the data center and regional context, see Public Cloud.

Related documentation

Security on Thalassa Cloud spans platform controls (this page) and customer-configurable controls. Use the resources below to harden your own workloads.

Platform and compliance

Identity and access

Secrets and encryption

Network and workload security