<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog &amp; Articles on Thalassa Cloud - European Cloud Services</title><link>https://thalassa.cloud/blog/</link><description>Recent content in Blog &amp; Articles on Thalassa Cloud - European Cloud Services</description><generator>Hugo -- gohugo.io</generator><language>en-US</language><atom:link href="https://thalassa.cloud/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Browser OIDC login for tcloud CLI</title><link>https://thalassa.cloud/blog/2026/07/07/browser-oidc-login-for-tcloud-cli/</link><pubDate>Tue, 07 Jul 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/07/07/browser-oidc-login-for-tcloud-cli/</guid><description>Until now, the default way to authenticate tcloud was a Personal Access Token (PAT): create one in the Console, paste it into tcloud context create, and hope it never ends up in shell history, a dotfile, or a shared screen recording. That works for automation, but it is a poor default for engineers who just want to manage clusters from a laptop.
With tcloud v0.20.0, browser-based OIDC login is the default.</description></item><item><title>Exporting audit logs for compliance and security review</title><link>https://thalassa.cloud/blog/2026/06/25/exporting-audit-logs-for-compliance-and-security-review/</link><pubDate>Thu, 25 Jun 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/06/25/exporting-audit-logs-for-compliance-and-security-review/</guid><description>Every API call in your Thalassa Cloud organisation leaves a trace. Audit logs record who did what, when, and from where - VPC changes, Kubernetes cluster updates, KMS crypto operations, secret access, and failed authentication attempts. That trail is essential for incident response, access reviews, and compliance evidence.
Audit logging is enabled by default for every organisation. Entries are immutable: they cannot be modified or deleted through the API. You can browse logs in the console or query them via the audit API, but for compliance archives, SIEM ingestion, or periodic security reviews you often need a bulk export.</description></item><item><title>Expose workloads with Gateway API and kgateway on Thalassa Cloud Kubernetes</title><link>https://thalassa.cloud/blog/2026/06/22/expose-workloads-with-gateway-api-and-kgateway-on-thalassa-cloud-kubernetes/</link><pubDate>Mon, 22 Jun 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/06/22/expose-workloads-with-gateway-api-and-kgateway-on-thalassa-cloud-kubernetes/</guid><description>Ingress controllers have served Kubernetes well for years, but they bundle concerns that teams often want to separate: platform operators manage the edge, while application developers attach routes to their services. The Kubernetes Gateway API was designed for that approach, and kgateway implements it with Envoy as the data plane.
On Thalassa Cloud Kubernetes, each Gateway you create provisions an Envoy proxy and a LoadBalancer Service backed by a VPC Load Balancer.</description></item><item><title>Authoritative DNS now in Early Access</title><link>https://thalassa.cloud/blog/2026/06/18/authoritative-dns-now-in-early-access/</link><pubDate>Thu, 18 Jun 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/06/18/authoritative-dns-now-in-early-access/</guid><description>Teams running workloads on Thalassa Cloud still had to host DNS with a separate provider. For organisations that use Thalassa for European data sovereignty, that left domain records outside the platform.
We heard from several customers that they prefer managing infrastructure and DNS through a single vendor: the same console, API, and audit trail they already use for VMs, Kubernetes, and load balancers, rather than maintaining zones at a third-party DNS service.</description></item><item><title>Secrets Manager now available in Early Access</title><link>https://thalassa.cloud/blog/2026/06/15/secrets-manager-now-available-in-early-access/</link><pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/06/15/secrets-manager-now-available-in-early-access/</guid><description>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.</description></item><item><title>Thalassa Cloud Launches Key Management Service in Early Access</title><link>https://thalassa.cloud/blog/2026/06/11/thalassa-cloud-launches-key-management-service-in-early-access/</link><pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/06/11/thalassa-cloud-launches-key-management-service-in-early-access/</guid><description>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.</description></item><item><title>Working with Thalassa Container Registry from Kubernetes</title><link>https://thalassa.cloud/blog/2026/06/11/working-with-thalassa-container-registry-from-kubernetes/</link><pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/06/11/working-with-thalassa-container-registry-from-kubernetes/</guid><description>You&amp;rsquo;ve pushed an image to Thalassa Cloud Container Registry. Now you want your Kubernetes cluster to pull it. Good news: there&amp;rsquo;s nothing exotic about this. It&amp;rsquo;s the same imagePullSecrets flow you&amp;rsquo;d use with any private registry - Docker Hub, ECR, whatever you&amp;rsquo;ve worked with before.
This post walks you through it step by step, from credentials to a running pod. If you want the full reference, the Kubernetes guide has that covered.</description></item><item><title>Kubernetes Cluster provisioning, without hardcoded secrets</title><link>https://thalassa.cloud/blog/2026/05/27/kubernetes-cluster-provisioning-without-hardcoded-secrets/</link><pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/05/27/kubernetes-cluster-provisioning-without-hardcoded-secrets/</guid><description>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&amp;rsquo;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.</description></item><item><title>CVE-2026-31431 (Copy Fail): patched Kubernetes images on Thalassa Cloud</title><link>https://thalassa.cloud/blog/2026/05/01/cve-2026-31431-copy-fail-patched-kubernetes-images-on-thalassa-cloud/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/05/01/cve-2026-31431-copy-fail-patched-kubernetes-images-on-thalassa-cloud/</guid><description>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.</description></item><item><title>Bootstrap workload identity with tcloud. GitHub, GitLab, and Kubernetes</title><link>https://thalassa.cloud/blog/2026/03/24/bootstrap-workload-identity-with-tcloud.-github-gitlab-and-kubernetes/</link><pubDate>Tue, 24 Mar 2026 00:00:00 +0000</pubDate><guid>https://thalassa.cloud/blog/2026/03/24/bootstrap-workload-identity-with-tcloud.-github-gitlab-and-kubernetes/</guid><description>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.</description></item></channel></rss>