A Sovereign Kubernetes Cluster: Keeping Health Data Inside One Jurisdiction on PaaS

A procurement questionnaire from a hospital group rarely asks whether you run Kubernetes. It asks where the data is processed, who can reach it, how it is encrypted in transit and at rest, and what happens when a node fails. This post follows a health-technology vendor we will call Caduceus Systems as it answers those questions for a patient-scheduling product by running its Kubernetes cluster on MassiveGRID PaaS, which is built on Virtuozzo Application Platform (formerly Jelastic), in one region and with every network path written down.

Start with the region, not the cluster

The first decision was geographic. MassiveGRID runs regions in New York, London, Frankfurt and Singapore, and the hospital group is in Germany. Caduceus chose Frankfurt in the installer, and every node of the Kubernetes Cluster package, control plane, workers, the shared storage container behind the NFS provisioner and the ingress, was created there. The platform's regions are separate hardware sets under one dashboard, so the choice is a dropdown rather than a separate account, and the environment's region label is visible next to it forever after.

That answers the first questionnaire item with one sentence: all processing occurs in Frankfurt, Germany, at facilities operated by an ISO 9001 certified, GDPR-compliant provider. It also settles a subtler point. Because the platform can migrate environments between regions, Caduceus documented that migration is a deliberate, logged action available only to accounts with the right role, not something that happens automatically.

Drawing the network before deploying a pod

The security officer's diagram had four boxes: the internet, the ingress, the cluster and the database. The platform provided a control for each edge.

• Internet to ingress. The Traefik ingress node has a public IPv4 address, and the Let's Encrypt add-on terminates TLS there. The node's container firewall denies every inbound connection not matched by a rule; the only rules allow 443 from the internet and the Kubernetes API port from the vendor's office VPN range. Access through the platform's shared load balancer is switched off for the layer, so the environment domain does not offer a second, unintended entry point.
• Ingress to workers, workers to control plane. These stay on the platform's internal network. Every environment in the product lives in one environment group with network isolation enabled, which means containers outside the group cannot open connections to anything inside it, even from another environment on the same account.
• Cluster to database. Patient data lives in a PostgreSQL primary-secondary cluster in its own environment inside the same isolated group. The PostgreSQL SSL/TLS add-on enforces encrypted connections, so even internal traffic between the pods and the database is encrypted, and a firewall rule on the database layer allows connections only from the worker layer, a rule the platform keeps current as workers are added or removed by scaling.

Endpoints, the platform feature that exposes a container port through the shared load balancer without a public IP, were explicitly not used, and the review notes say why: an endpoint is a path to the database from the internet, and the design has exactly one internet-facing port.

Isolation the auditor can see

Several controls that a Kubernetes team would normally implement inside the cluster are provided underneath it, and Caduceus found that auditors preferred it that way because the controls are visible in the dashboard rather than in YAML.

Every node is an isolated container placed on a different physical host from the other nodes in its layer, so a compromised worker has no shared kernel namespace with the database and no shared host with the other workers. The container firewall rules, the isolated group, the region and the SSL status are all listed in the environment's settings, and the security officer exports screenshots of them for the evidence pack. Account collaboration gives the hospital's own IT team a read-only role on the environment group, so they can verify the configuration themselves without being able to change it.

Inside the cluster the usual Kubernetes controls still apply: network policies between namespaces, RBAC, pod security standards, image scanning in the pipeline. The point of the platform layer is that those controls are the second line, not the only one.

Availability as a compliance requirement

The questionnaire treats availability as a security property, and the hospital's contract requires the scheduling service to be reachable at all times during clinic hours. The platform's contribution is architectural. Nodes in a layer never share a physical host, and a host that degrades has its containers live-migrated to another within about thirty seconds, without restarts. The Kubernetes control plane runs as multiple masters, workers are added on load triggers before the existing ones saturate, and the PostgreSQL cluster's Pgpool-II layer promotes a standby automatically if the primary fails. MassiveGRID backs the infrastructure with a 100% uptime SLA.

Backups were the last item. The Database Backup/Restore add-on writes encrypted-in-transit PostgreSQL dumps on a schedule to a Backup Storage node, itself inside the isolated group and inside Frankfurt, with a retention count that matches the hospital's policy. Restores are one click and have been rehearsed on a clone of the environment, which is a sentence the auditor wrote down.

What the evidence pack contained

Caduceus passed the review. The engineering lesson they took away was that a sovereign deployment is mostly a documentation exercise, and that a platform which makes the network path explicit, region, group, firewall, SSL, makes the documentation short.

Frequently Asked Questions

Does network isolation replace Kubernetes network policies?

No, it complements them. Network isolation on MassiveGRID PaaS controls connections between environments on the platform's internal network, so nothing outside the isolated group can reach the cluster or the database. Kubernetes network policies control traffic between pods inside the cluster. A sovereign design uses both.

Can the hospital audit the configuration without administrative access?

Yes. Account collaboration lets the environment owner grant a read-only role scoped to an environment group. The collaborator sees topology, region, firewall rules, SSL status and statistics for those environments but cannot change or delete anything, and the owner remains responsible for all charges.

What if a second region is needed for disaster recovery?

Add it deliberately. The PostgreSQL and MariaDB multi-region cluster packages replicate databases to a second MassiveGRID region, and environments can be cloned and migrated offline to another region. In a sovereignty context the decision to replicate outside the primary jurisdiction is a data-protection decision first, so document it as such before enabling it.