Declare VPCs, subnets, NAT gateways, security groups, and more as custom resources reconciled to Thalassa for GitOps-friendly infrastructure.
We’re launching the Thalassa Cloud IaaS Controller in beta. It is a Kubernetes controller that extends the API with Custom Resource Definitions (CRDs) for Thalassa Cloud Infrastructure as a Service. You define VPCs, subnets, NAT gateways, route tables and routes, security groups, target groups, and VPC peering connections as Kubernetes resources; the controller reconciles them against the Thalassa IaaS API so cloud state matches what you commit-kubectl, standard RBAC, and GitOps (Argo CD, Flux, and similar) all apply. That keeps network and load-balancing infrastructure in the same declarative loop as you’re used to for your application workloads, allowing you to stick to one stack for policy management, validation, etc.
The iaas-controller and its CRDs are distributed as OCI Helm charts, so you can install them directly using Helm. Begin by installing the iaas-controller-crds chart to provide the necessary Custom Resource Definitions, followed by the main iaas-controller chart itself. Charts are hosted at oci://ghcr.io/thalassa-cloud/charts/.
The default helm install uses OIDC token exchange backed by workload identity federation. The controller sends the in-cluster service account token to Thalassa’s token endpoint to exchange it for an API access token. This eliminates the need for long-lived secrets or access credentials. You will need tcloud with permission to bootstrap workload identity, plus your organisation and cluster identifiers in Thalassa. New to the CLI? See the CLI documentation.
Bootstrap the federated identity to allow service account impersonation Adjust cluster ID, (kubernetes) namespace, (kubernetes) service account name, and role to match your environment; (default chart service account is often iaas-controller in namespace thalassa-iaas-controller):
Thalassa Cloudexport ORGANISATION_ID="<your-org-id>"
export CLUSTER_ID="<your-cluster-id>"
tcloud iam workload-identity-federation bootstrap kubernetes \
--cluster "$CLUSTER_ID" \
--namespace thalassa-iaas-controller \
--service-account iaas-controller \
--role iaas:FullAdminAccess
The above will automatically provision a Serviceaccount in Thalassa Cloud IAM, bind the iaas:FullAdminAccess role to it and setup the workload identity federation to allow the Kubernetes Serviceaccount to impersonate the Thalassa Cloud Serviceaccount.
The bootstrap command will output what has been provisioned, as well as an example on how to use it. Copy the Thalassa service account ID from the output (for example sa-…) for the next step.
The chart can mount a projected service account token and pass --thalassa-subject-token-file so the controller. This is configured by default, all you need to provide is the organisation and serviceaccount IDs;
thalassa:
enabled: true
url: "https://api.thalassa.cloud/"
organisation: "<ORGANISATION_ID>"
authMethod: tokenExchange
tokenExchange:
serviceAccountId: "<THALASSA_SERVICE_ACCOUNT_ID>"
projectedToken:
enabled: true
audience: "https://api.thalassa.cloud/"
serviceAccount:
create: true
Installinng the IaaS Controller looks like this;
export ORGANISATION_ID="<ORGANISATION_ID>"
export THALASSA_SERVICE_ACCOUNT_ID="<THALASSA_SERVICE_ACCOUNT_ID>"
helm upgrade --install iaas-controller-crds oci://ghcr.io/thalassa-cloud/charts/iaas-controller-crds:v0.3.0 \
--namespace thalassa-iaas-controller \
--create-namespace
helm upgrade --install iaas-controller oci://ghcr.io/thalassa-cloud/charts/iaas-controller:v0.3.0 \
--namespace thalassa-iaas-controller \
--create-namespace \
--set thalassa.organisation="$ORGANISATION_ID" \
--set thalassa.tokenExchange.serviceAccountId="$THALASSA_SERVICE_ACCOUNT_ID" \
--set enableServiceMonitor=false
Other auth methods (personal access token, access credentials) and additional chart options are documented in the chart README. For step-by-step copy/paste installs and Flux CD examples, see the deployment guides shipped with the project.
Once the IaaS Controller is installed, you can provision Infrastructure in Thalassa Cloud through Kubernetes resources.
Here is how to configure a VPC, Subnet and NAT gateway;
apiVersion: iaas.controllers.thalassa.cloud/v1
kind: VPC
metadata:
name: vpc-sample
spec:
region: nl-01
cidrBlocks:
- "10.0.0.0/16"
description: "Sample VPC"
---
apiVersion: iaas.controllers.thalassa.cloud/v1
kind: Subnet
metadata:
name: subnet-sample
spec:
vpcRef:
name: vpc-sample
cidr: "10.0.1.0/24"
description: "Sample subnet"
---
apiVersion: iaas.controllers.thalassa.cloud/v1
kind: NatGateway
metadata:
name: natgateway-sample
spec:
subnetRef:
name: subnet-sample
configureDefaultRoute: true
description: "Sample NAT gateway for outbound internet"
# Optional: reference security groups by Kubernetes resource or by Thalassa identity
# securityGroupRefs:
# - name: securitygroup-sample
# - identity: "sg-abc123"
The controller gives you a single reconciliation loop: desired state lives in Git (or your CD pipeline), Kubernetes holds the CRs, and Thalassa reflects the outcome-so you review diffs, roll forward and back, and debug with the same kubectl and controller logs you already use for workloads. RBAC on CRDs, audit logs, and namespace-scoped resources map cleanly to how teams own clusters and environments, and token exchange keeps credentials short-lived instead of copying API keys into clusters.
If you are standardising on GitOps or tightening network-as-code next to your apps, the IaaS controller is the path to treat Thalassa networking like any other Kubernetes-managed surface.
The IaaS controller is part of a broader direction: specialized controllers that further integrates Kubernetes to Thalassa Cloud services. Next in that line are integrations such as object storage-provisioning and consuming buckets from the cluster, as well as managed Postgres, where a controller would drive database lifecycle (create, scale, credentials, and wiring into workloads) against our DBaaS APIs.
Watch our roadmap and product updates for announcements as these controllers land.
