Platform · Multi-Cloud
Every cloud, one pane of glass.
Ship to AWS, Google Cloud, and Azure, plus self-managed clusters, from one platform. Managed or self-managed, Kubentic speaks every distro. No console hopping, no cloud-specific CLIs.
- AWS, GCP & Azure from one interface
- EKS, GKE, AKS & self-managed
- One control plane across every cloud
Overview
Why teams reach for multi-cloud on Kubentic
Most teams don't choose three clouds, they end up there. An acquisition brings GCP, an enterprise deal mandates Azure, and the original stack was always on AWS. The tax is real: three consoles, three CLIs, three IAM models, three audit logs, and an on-call engineer who has to remember which one they're in during an incident. Kubentic collapses that into one control plane, so provider becomes a detail rather than a context switch.
Under the hood, Kubentic connects to each cloud with least-privilege, short-lived credentials, AssumeRole on AWS, Workload Identity on GCP, a scoped service principal on Azure, and holds no standing keys. It then normalizes EKS, GKE, AKS and self-managed into one object model, so a node pool, namespace or workload reads the same everywhere. Every other capability, the shipping wizard, live monitoring, Foresight, the browser terminal, RBAC and the audit log, runs against that unified model, which is what makes a single view across every cloud real instead of three dashboards in a trench coat.
Multi-Cloud
One platform. Every major cloud.
No console hopping
Ship and operate across AWS, GCP and Azure without ever leaving Kubentic.
Every distro
EKS, GKE, AKS and self-managed clusters, the same guided flow across all of them.
One bill of health
One view for every environment, no matter which cloud it runs on.
Capabilities
Everything inside Multi-Cloud.
Per-cloud scoped IAM, no standing keys
Kubentic connects to each provider with least-privilege, short-lived credentials: an AssumeRole IAM role on AWS, a Workload Identity service account on GCP, a scoped service principal on Azure. It stores no standing keys, and you can revoke or tighten any one cloud's access without touching the others.
Normalized fleet inventory across providers
EKS, GKE, AKS and self-managed resolve into one object model, node pools, namespaces, workloads and storage classes read identically no matter who runs them. Filter by cloud, region or distro and get an apples-to-apples fleet list instead of reconciling three consoles by hand.
End-of-support tracking, not just version numbers
Kubentic tracks each provider's Kubernetes support window, so a GKE cluster three minors behind and nearing deprecation surfaces next to your EKS and AKS fleet, with its EOS date attached, not buried in a per-cloud release note. You see what's about to fall out of support before the provider forces the upgrade.
Cross-cloud RBAC in a single grant
The four built-in roles, Viewer, Operator, Admin, Owner, apply per cluster and per namespace regardless of which cloud a cluster runs on. Grant a team Operator on prod across AWS and Azure in one action instead of authoring and reconciling three separate cloud IAM policies.
Foresight and Browser Terminal, agentless on every cloud
Predictive anomaly detection and the JWT-authenticated command-line terminal behave identically against an EKS node in us-east-1 or a self-managed box elsewhere. There are no per-cloud agents to install and no separate tooling to learn, one shell and one signal for the whole fleet.
One audit trail that replaces three cloud logs
Every ship, terminal session and permission change across all connected clouds lands in one timestamped, identity-stamped log, exportable as CSV or JSON. You answer 'who touched prod?' once instead of correlating CloudTrail, Cloud Audit Logs and Azure Activity Log by hand.
How it works
Any cloud, under one roof.
01
Connect your clouds
Authenticate AWS, GCP and Azure once, with scoped, short-lived tokens and nothing stored.
02
Ship anywhere
The same guided wizard ships to any provider or distro you connect.
03
Operate as one
Monitoring, terminal, Foresight and RBAC span every cloud from one console.
Built for real work
Where Multi-Cloud earns its keep.
The team that grew into three clouds by accident
AWS for the original product, GCP after a data-science acquisition, Azure because an enterprise customer required it. Instead of three consoles and three CLIs, the platform team connects all three and runs the whole estate from one fleet view: same wizard to ship, same terminal to debug, same audit log to answer the compliance questionnaire.
Migrating off self-managed with no big-bang cutover
A platform team imports their legacy self-managed cluster, stands up a fresh EKS cluster from the same wizard, and runs both under one control plane while draining workloads over weeks. Monitoring and RBAC span old and new side by side, so nothing goes dark during the move and there's no risky flag day.
Placing workloads where they're cheapest or closest
An eng leader ships latency-sensitive services to whichever cloud has a region near the customer and cost-sensitive batch jobs to whichever is cheapest, without engineers needing EKS, GKE and AKS expertise each. Kubentic abstracts the per-cloud mechanics so provider choice becomes a placement decision, not a retraining project.
At a glance
The technical details.
- Clouds supported
- AWS, Google Cloud, Microsoft Azure
- Cluster types
- EKS, GKE, AKS, self-managed (4 total)
- Cloud auth model
- AWS AssumeRole, GCP Workload Identity, Azure service principal, scoped, short-lived tokens, no keys stored
- Kubernetes versions
- Managed per distro (e.g. 1.30), tracked against each cloud's support window and EOS dates
- Cross-cloud RBAC
- Viewer, Operator, Admin, Owner, per cluster and per namespace, any provider
- Audit export
- One unified log across all clouds; CSV or JSON; identity- and timestamp-stamped
- Clouds
- 3
- Cluster types
- 4
- Control plane
- 1
- Console hops
- 0
Clouds
Cluster types
Control plane
Console hops
FAQ
Questions, answered.
Does Kubentic need admin or root access to my cloud accounts?
No. It connects with least-privilege, scoped credentials, an IAM role assumed on AWS, a Workload Identity service account on GCP, a scoped service principal on Azure. The tokens are short-lived and nothing is stored on Kubentic servers, so you grant exactly the permissions the platform needs and can tighten or revoke them per cloud at any time.
Can I connect just one cloud now and add others later?
Yes. Each cloud connection is independent, start with AWS today, add GCP and Azure whenever you're ready, and remove any one without affecting the rest. The same guided wizard and fleet view apply whether you run one cloud or all three.
Do I have to learn each cloud's Kubernetes flavor to operate the fleet?
No, and that's the point. EKS, GKE, AKS and self-managed are normalized into one common model, so shipping, monitoring, the browser terminal, RBAC and Foresight behave identically across them. Provider-specific quirks stay under the hood instead of on your engineers' plates.
How does access control work when a team spans multiple clouds?
The four built-in roles, Viewer, Operator, Admin, Owner, apply per cluster and per namespace regardless of which cloud the cluster runs on. You grant a team Operator on prod across AWS and Azure in one place rather than hand-reconciling three separate cloud IAM policies, and every grant lands in the audit log.
Can I get one audit trail across all three clouds for compliance?
Yes. Every ship, terminal session and permission change across every connected cloud lands in a single timestamped, identity-stamped log, exportable as CSV or JSON. Instead of correlating CloudTrail, Cloud Audit Logs and Azure Activity Log by hand, you answer 'who did what, where, and when?' once for the entire fleet.
“We run three clouds and twenty clusters. Kubentic is the only tool that actually gives us a unified view without making us learn three different CLIs.”
Your first environment is
15 minutes away.
No credit card. No infrastructure expertise. Just a cloud account and a browser, and you're shipping.
Free plan · No credit card · Cancel any time