Security and data protection

Cloudfleet runs its management layer and the Kubernetes control planes of your clusters in Cloudfleet’s cloud environment. Your workloads, volumes, Pod logs, and application data do not run there. They run on the infrastructure you choose: any cloud provider, your own data center, or both.

This page describes what Cloudfleet stores, where it stores it, and the controls that limit who can reach it, including our infrastructure provider and our own staff.

Architecture

Cloudfleet has three layers, and only the first two run in Cloudfleet’s cloud environment.

The management layer is the Cloudfleet API and Console. It holds organizations, users, billing data, and the region of each cluster. Nothing stored inside your clusters reaches it.

Each cluster has its own control plane, which runs the Kubernetes API server and the cluster data store in the control plane region you choose for the cluster. Control plane components and data stores are never shared between clusters, not even within the same organization, and are isolated from each other at the network and runtime level. Basic clusters run their control planes on hardware shared with other customers, while Pro and Enterprise clusters run them on dedicated resources.

The data plane is your nodes, on any cloud provider or on-premises. Pods, volumes, and Pod logs stay on them. Nodes reach each other and the control plane over an encrypted WireGuard® overlay, and the Kubernetes API uses TLS on top of it. See Networking architecture.

What data Cloudfleet holds

Cloudfleet holds what it needs to run your clusters and bill you. It does not collect workload data, Pod logs, or volume contents.

The Data Processing Agreement lists all sub-processors that support the service.

When you delete a cluster, its control plane and all live data are deleted immediately. Backups and infrastructure logs are deleted automatically within 30 days. Before you delete a cluster, you can export its resources through the Kubernetes API with standard tools such as kubectl.

How the control plane is hosted

A Kubernetes control plane needs high availability and fast, predictable operations. Pro and Enterprise control planes run with multiple replicas across physically separate availability zones, as described in Cluster types. Our infrastructure provider’s ISO/IEC 27001 certification and SOC 2 reports cover the physical and environmental controls of the hosting layer. Control plane regions in Europe and North America keep the Kubernetes API close to your nodes.

The control plane holds only cluster state. Your nodes, and the data they process, run wherever you choose.

Encryption

The cluster data store is encrypted at rest with AES-256 at the disk level, so all cluster data is covered, not only Secrets. Backups are encrypted in transit and at rest. On Enterprise clusters, Confidential Control Plane also encrypts every Kubernetes object in the API server before it is stored, with keys held in your own HSM or cloud KMS.

All external traffic, including the Kubernetes API, uses TLS 1.2 or later. Node-to-node traffic runs over WireGuard®, even when the underlying network is already encrypted.

Access by Cloudfleet staff

Cloudfleet staff operate control plane components for upgrades, scaling, and health monitoring. They do not access your workloads, application data, or Secrets unless you authorize it. Routine support access does not include Kubernetes Secrets. Access to your workloads, application data, or Secrets happens only with your explicit approval, for a limited time, for example during a support session.

All staff with production access are located in Germany, and no administrative access takes place from outside the EU. Every account is personal and protected with multi-factor authentication and passkeys. There are no shared credentials, and permissions follow least privilege. Access is revoked immediately when someone leaves Cloudfleet, with automated checks, and all staff are bound by written confidentiality obligations.

Logging and audit

Administrative actions and access events are written to append-only (WORM) storage, with automated alerting on anomalies. On Enterprise clusters, the Kubernetes audit logs of your clusters are delivered to your own infrastructure. Cloudfleet does not keep them.

Security policies and infrastructure are defined as code. Admission and configuration policies are enforced in CI and in the cluster, so every change is reviewed and recorded in the commit history.

Regions and data residency

A control plane region is the location where a cluster’s control plane runs, together with its cluster data store and the backups of that data store. You choose it when you create a cluster, and you cannot change it later. It does not limit where your nodes run: a cluster can have nodes on any provider and in any country at the same time.

Cloudfleet has two control plane regions:

The 1a suffix is part of the region name, not an availability zone: Pro and Enterprise control planes span several availability zones within the region. Cluster state and its backups stay in the region you choose. Cloudfleet’s contract for both regions is with Google Cloud EMEA Limited (Ireland).

Control planes need capacity on demand and must stay available when an availability zone fails. At Cloudfleet’s scale, only a hyperscaler provides both. Cloudfleet uses Google Cloud only for foundational infrastructure: compute, storage and networking. Cloudfleet staff operate the control planes and the cluster data stores on it. The infrastructure provider does not operate them and does not process your cluster data as a service.

Cloudfleet configures its infrastructure so that personnel of the infrastructure provider cannot access Cloudfleet customer data or the contents of CFKE control planes without authorization. Data at rest is encrypted. Enterprise clusters can use Confidential Control Plane, which moves key management to a key manager that you fully control. Without your key, neither the infrastructure provider nor Cloudfleet can read the cluster data.

Government requests for data

Cloudfleet does not disclose customer data to a government, law enforcement or intelligence agency unless the law requires it. Cloudfleet reviews every request, challenges requests that are unclear, too broad or not legally valid, and discloses only the minimum the law requires. Cloudfleet first asks the agency to request the data from you directly, and notifies you before disclosing anything, unless the law prohibits it. The infrastructure provider can receive requests for data under laws such as the US CLOUD Act. With Confidential Control Plane, it holds no key that can decrypt your cluster data.

If the infrastructure provider of a region ever changes, data residency stays the same, and you get advance written notice of the subprocessor change.

Compliance

Our information security management system is designed in accordance with ISO/IEC 27001 and the SOC 2 Trust Services Criteria.

We notify you of a personal data breach affecting your data within 24 hours of becoming aware of it. To date, Cloudfleet has had no security incident affecting customer data, no proceedings by a supervisory authority, and no request for customer data from any government, law enforcement, or intelligence agency.

Stricter requirements

You can run the whole data plane on-premises or on European providers with self-managed nodes. This includes infrastructure qualified under SecNumCloud, the certification of the French cybersecurity agency ANSSI. On Enterprise clusters, Confidential Control Plane also encrypts all cluster data with keys held in your own HSM or cloud KMS, and runs the control plane on Confidential VMs.

Reporting a vulnerability

Report security issues to [email protected].