Most platforms secure Kubernetes with settings you have to get right. Aether narrows the surface instead: nodes run an OS with no shell and no SSH service, your control plane runs as pods on a per-tenant datastore rather than on a VM you operate, and every LoadBalancer Service gets its own VM instead of a shared proxy. These are how the platform is built, not options you enable — which reduces what can be misconfigured without removing your responsibility for what runs inside the cluster.
Fewer moving parts in your hands means fewer things to configure wrongly — and the honest list of what is still yours.
All seven are configured automatically on every cluster bootstrap — you don't write a single line of platform security YAML to get them. Policy inside your cluster, such as your own NetworkPolicies and RBAC, is still yours to write.
Every hypervisor enforces firewall rules at the virtualization layer, under the VMs — closing ports your workloads never see.
Each cluster gets its own layer-2 network and private subnet. There is no shared segment for lateral movement between tenants.
eBPF-based networking with L3–L7 policy inside the cluster, ready for your own NetworkPolicies from the first pod.
Talos Linux: no SSH, no shell, no package manager, read-only root, API-only management. There is nothing to log in to.
Your API server runs as hardened pods in our management cluster on a per-tenant, role-isolated datastore. There is no control-plane VM in your estate to patch or lose, and the management layer is not reachable from tenant networks.
Aether Identity is single sign-on for the portal and the REST API: org-scoped roles and MFA. Your Kubernetes API is a separate credential path — every cluster answers on its own dedicated public IPv4, protected by TLS and Kubernetes authentication — the admin client certificate, or ServiceAccount tokens you mint inside the cluster and scope with Kubernetes RBAC. RBAC does not scope the admin certificate: it is in the system:masters group, which Kubernetes exempts from authorization. Access to the portal and the API is revoked centrally in one place. The kubeconfig you download is not: it is a standalone credential, and the section below sets out exactly what that means.
Every LoadBalancer Service gets its own load-balancer VM and IP with per-service firewalling — no shared ingress proxy sits between tenants.
Aether runs one region today — eu-fi · Helsinki, Finland — and it is a complete, independent deployment of the platform: compute, storage, identity, registry, observability and billing records. Your workloads and the platform data about them live there. Aether is operated by EAGLE VERSE SRL, a company registered in Romania.
One exception is worth stating plainly: payment data is processed by Stripe, which may transfer it outside the EU under standard contractual clauses. What is collected, and on what basis, is set out in the privacy policy — read it rather than taking a marketing page's word for it. Aether makes no claim about immunity from any country's law.
Billing records are held in eu-fi; the payment data behind them is processed by Stripe, which may transfer it outside the EU under standard contractual clauses.
Isolation between tenants is ours. Security inside your cluster is yours — and no platform can take that part off you.
Aether continuously archives your control-plane datastore. It does not back up the data inside your PersistentVolumes — schedule that yourself. There is no SLA, no uptime commitment and no service credits today; see the terms of service.
The protections above are configured for you. These two are yours to set, and the defaults are worth knowing before you rely on them.
Every cluster has a public API endpoint, and an empty authorized-network list means that endpoint accepts connections from any source address. Authentication still applies — a valid Kubernetes credential, whether a client certificate or a ServiceAccount token — but no address is turned away at the network layer. Setting one or more CIDRs restricts the endpoint at the firewall and at the proxy. On the public endpoint, the cluster's own workers and the platform are always allowed in addition to your list, so a list can never lock the platform out of your control plane. The list also governs Aether's kubectl proxy through the platform API — a preview that is on in Aether's own development environment and off in production. The list is edited in the portal (cluster → API server access → Edit) or over the REST API.
The kubeconfig you download carries a client certificate for kubernetes-admin in the system:masters group, valid for one year from the cluster's creation. It is a standalone credential: it does not expire when someone leaves your organization, and removing a member from the portal does not revoke a kubeconfig they already downloaded. There is no self-service rotation or revocation today — if a kubeconfig may have been exposed, the supported responses are to delete and recreate the cluster, or to open a support request. RBAC is not a control over this credential either: Kubernetes exempts system:masters from authorization, so no Role or RoleBinding can narrow what the admin kubeconfig may do, and none can revoke it. RBAC governs the credentials you create inside the cluster — ServiceAccount tokens, and certificates you sign — which is one more reason to hand those out, scoped to the access someone actually needs, rather than sharing the admin file. A downloaded copy is detached from the cluster: after an endpoint change, download it again.
Automatic and customer-managed are different lists. Aether configures the per-cluster VLAN, the host and SDN firewalls, the immutable node OS and the per-tenant control plane on every cluster. You manage the authorized-network list, Kubernetes RBAC, your NetworkPolicies, and who holds a kubeconfig.
Static analysis and secret scanning on every change, pinned and scanned container images, restricted pod security standards, least-privilege service accounts, and continuous datastore backups. Vulnerability scanning runs on every image pushed to your registry.
a SOC 2 Type I attestation, a standard GDPR data-processing agreement with a public sub-processor register, and ISO 27001 — sequenced ahead of the second region. None of these exist today: this is a roadmap, not a set of badges. Ask where they stand at legal@aetherplatform.cloud before you buy.
Concretely: no separate data-processing agreement is available today. The terms of service and the privacy policy are the whole agreement between us — read the privacy policy's data-processing section for what that covers.
The docs describe exactly how the platform works; legal and privacy questions go to legal@aetherplatform.cloud.