Secrets Manager now available in Early Access

secrets manager kms
2026-06-15
By Thalassa Cloud

Teams running workloads on Thalassa Cloud often still store credentials with a separate secrets service. Some run OpenBao or HashiCorp Vault themselves — which works, but adds operational overhead on top of the application stack: deployment, upgrades, backup, and ongoing monitoring. Others rely on another third-party tool or vendor. For organisations that use Thalassa for European data sovereignty, that keeps sensitive values outside the platform they chose for compute and storage.

Latest Posts

Secrets Manager now available in Early Access

Teams running workloads on Thalassa Cloud often still store credentials with a separate secrets service. Some run OpenBao or HashiCorp Vault themselves — which works, but adds operational overhead on top of the application stack: deployment, upgrades, backup, and ongoing monitoring. Others rely on another third-party tool or vendor. For organisations that use Thalassa for European data sovereignty, that keeps sensitive values outside the platform they chose for compute and storage.

Thalassa Cloud Launches Key Management Service in Early Access

Last year we shared that we were building KMS and Secrets Manager for Thalassa Cloud. Today we are happy to be opening our Key Management Service (KMS) in Early Access. What is KMS, and why does it matter? A Key Management Service (KMS) is where you create, store, and control the cryptographic keys used across your environment. Applications and platform services call the KMS API to encrypt data, verify signatures, or generate keyed hashes — instead of embedding key material in configuration files or managing crypto libraries per service.

Kubernetes Cluster provisioning, without hardcoded secrets

You can deploy a Kubernetes cluster in 5 minutes using GitLab CI and Terraform—without storing any secrets in your pipeline. This guide shows you how to use OIDC (OpenID Connect) for secure authentication and deploy a production-ready cluster. By the end, you’ll have a working pipeline that creates and manages your Kubernetes cluster automatically. Why Use OIDC? Usually, CI/CD pipelines need API tokens stored as secrets. This causes problems. You must manually rotate tokens, which is easy to forget.

CVE-2026-31431 (Copy Fail): patched Kubernetes images on Thalassa Cloud

CVE-2026-31431, known as Copy Fail, is a Linux kernel local privilege escalation affecting a wide range of kernels from 2017 until distributors ship the fix. On Kubernetes Clusters that may execute potentially malicious workloads (i.g. third party container images), the vulnerability may facilitate container escape scenarios (from a pod to the host). Utilising microVMs or other isolated runtime classes may mitigate impact. Thalassa Cloud Kubernetes images v1.34.7-1 and v1.35.4-1 include kernel module updates that address CVE-2026-31431 by applying the recommended mitigation from Canonical for Ubuntu.

Bootstrap workload identity with tcloud. GitHub, GitLab, and Kubernetes

We want to eliminate static secrets wherever it is practical. Long-lived tokens in Git variables, copied into Terraform backends, or baked into cluster manifests rot slowly, leak easily, and rarely map cleanly to who actually called the API. Workload identity federation is a better default: a platform OIDC identity proves this pipeline or this service account ran the job, and Thalassa issues short-lived access in exchange. The tcloud iam workload-identity-federation bootstrap command is one piece of that puzzle.

Kubernetes v1.34.2-0 and v1.33.6-0: Security Fixes and Component Updates

We’re announcing two new Kubernetes releases in Thalassa Cloud: v1.34.2-0 and v1.33.6-0. These releases include security fixes that address high-severity vulnerabilities in runc, along with important component updates and stability improvements. Critical Security Fixes Both releases include runc 1.3.3, which fixes three high-severity security vulnerabilities: CVE-2025-31133 CVE-2025-52565 CVE-2025-52881 These vulnerabilities could allow full container breakouts by bypassing runc’s restrictions for writing to arbitrary /proc files. We recommend upgrading your clusters to these versions as soon as possible to mitigate these security risks.

Introducing VPC Peering on Thalassa Cloud

We are excited to announce the availability of VPC Peering on Thalassa Cloud. This feature lets you connect Virtual Private Clouds (VPCs) securely though our private network, enabling private network communication between VPCs without using the public internet or Site-to-Sites. It works across organisation accounts. Private Network Connections VPC Peering creates a direct network connection between two VPCs. Traffic between peered VPCs stays on the private network and never touches the public internet, providing secure, low-latency communication between your VPCs.