Every managed Kubernetes vendor advertises the same promise: "we run the control plane, you run the workloads." That split hides three genuinely different security models. AWS ships EKS with almost every control-plane log and network restriction turned off by default. Google ships GKE Autopilot with privileged containers, host networking, and hostPath mounts blocked before you write a line of YAML. Microsoft ships AKS with a legacy Azure AD integration path it has spent two years trying to retire, and in November 2023 disclosed CVE-2023-29332, an AKS-specific privilege escalation that let an attacker who could run a pod on a cluster retrieve the cluster's admin credentials. None of that shows up in a feature comparison table. Security teams choosing between EKS, GKE, and AKS — or auditing a multi-cloud fleet that already runs all three — need to know exactly where each provider's responsibility ends and where a misconfiguration becomes an incident.
What's actually different between the EKS, GKE, and AKS shared responsibility models?
All three providers manage the control plane (API server, etcd, scheduler) and leave node OS, workload configuration, and IAM wiring to the customer, but the boundary of "managed" is drawn in different places. EKS manages the control plane across three availability zones but by default exposes the API server on a public endpoint and enables zero of its five available control-plane log types (API server, audit, authenticator, controller manager, scheduler) — you must explicitly turn each on in the console, CLI, or Terraform and pay for the CloudWatch ingestion. GKE goes further: Google fully manages control-plane upgrades (unless you pin a static version) and Admin Activity audit logs cannot be disabled at all, which means every RBAC change and secret access at the control-plane level is captured whether you configured it or not. AKS sits in between — Microsoft manages the control plane and offers Azure Policy (built on Gatekeeper/OPA) for workload governance, but control-plane diagnostic logs and Microsoft Defender for Containers are both opt-in add-ons, not defaults. In practice, this means an EKS or AKS cluster stood up with terraform apply and no follow-up hardening pass ships with materially weaker visibility than a GKE cluster stood up the same way.
How do EKS, GKE, and AKS handle pod-to-cloud-API identity?
Each provider solved the "pods need AWS/GCP/Azure credentials" problem differently, and the maturity gap matters for lateral movement risk. AWS's original answer, IRSA (IAM Roles for Service Accounts), required standing up an OIDC identity provider per cluster and annotating service accounts with IAM role ARNs — workable but easy to misconfigure with overly broad trust policies. At re:Invent in November 2023, AWS shipped EKS Pod Identity as a simpler alternative that removes the OIDC provider step entirely, but both mechanisms coexist in production today, so an auditor has to check which one a given cluster uses. GKE's equivalent, Workload Identity Federation for GKE, has been the recommended pattern since 2021 and actively deprecates the older, riskier approach of mounting node-level service account keys inside pods — Google will not let you provision a new Autopilot cluster with the legacy metadata-server credential path enabled. AKS ties pod identity to Entra ID (formerly Azure AD) via workload identity federation, but Microsoft only completed retirement of the older "AKS-managed Azure AD" integration path in 2023, meaning clusters built before that migration may still be running the deprecated authentication flow with weaker group-membership guarantees. If you're inheriting clusters rather than building them, the identity mechanism in use — not just which cloud it's on — determines your actual blast radius.
Which platform has the most secure defaults out of the box?
GKE Autopilot, launched to general availability in February 2021, ships the most restrictive workload defaults of the three by design. Autopilot rejects privileged containers, blocks host networking and hostPath volume mounts, enforces seccomp profiles, and removes node-level SSH access entirely — there's no node to SSH into. GKE Standard mode doesn't inherit these guardrails automatically; you have to opt into Shielded GKE Nodes, Container-Optimized OS, and gVisor-based GKE Sandbox individually. EKS has no equivalent "secure by default" tier: a freshly created EKS cluster allows privileged pods, has a public API endpoint, and requires you to install and configure the Amazon VPC CNI's network policy support (or a third-party CNI like Calico) before NetworkPolicy resources do anything at all. AKS falls closer to EKS — Azure CNI vs. kubenet is a networking choice you make at cluster creation that determines whether NetworkPolicy is even honored, and Microsoft Defender for Containers, the runtime threat-detection layer, has to be enabled as an add-on per cluster or per subscription rather than shipping on. The practical takeaway: if your team lacks bandwidth for a hardening pass, Autopilot on GKE is the only one of the three that fails safe.
What CVEs have actually affected managed Kubernetes control planes?
The two most consequential recent CVEs hit different layers: one is a core Kubernetes design flaw present on all three clouds, the other is AKS-specific. CVE-2020-8554 ("Man in the Middle using LoadBalancer or ExternalIPs") is an unfixed architectural issue in upstream Kubernetes where any user able to create or edit Services can intercept traffic intended for other pods on the same cluster — because it's baked into the Service/ExternalIPs design rather than a patchable bug, EKS, GKE, and AKS are all equally exposed and the only mitigation is an admission controller (like Kyverno or OPA Gatekeeper) blocking arbitrary ExternalIPs. CVE-2021-25741, a kubelet symlink-exchange flaw allowing a subPath volume mount to escape to the host filesystem, carried a CVSS score of 8.8 and required a kubelet-version patch on every managed platform — a reminder that "managed control plane" doesn't mean "no CVE remediation work," since kubelet runs on the node, which the customer patches on EKS and AKS and Google auto-patches on GKE. The AKS-specific case, CVE-2023-29332, disclosed by Microsoft in November 2023, let an attacker with pod-creation access on a cluster retrieve the cluster's managed identity credentials and escalate to cluster-admin; Microsoft patched it server-side, but it's a concrete example of a vulnerability that existed only in one provider's control-plane implementation, not in upstream Kubernetes. Tracking which CVEs are "Kubernetes-the-project" issues versus "this-one-vendor's-integration" issues is the difference between patching a node pool and waiting on a cloud provider's fix.
Does supply chain security work the same way across EKS, GKE, and AKS?
No — image provenance and admission enforcement are the least standardized part of the three platforms. GKE has the most built-out native story: Binary Authorization lets you require cryptographic attestations (from a build system or vulnerability scanner) before an image can deploy, enforced at admission time across the cluster. EKS has no equivalent first-party admission control; AWS expects customers to bring their own policy engine (Kyverno, OPA Gatekeeper) and wire it to ECR image scanning results themselves, and ECR's basic scanning only covers OS packages, not language-level dependencies, unless you pay for ECR enhanced scanning (powered by Amazon Inspector). AKS relies on Azure Policy's Gatekeeper integration plus optional integration with Microsoft Defender for Containers' registry scanning, but — like EKS — nothing blocks an unscanned image from deploying unless you've explicitly built that policy. None of the three natively correlates "this base image has CVE-2024-XXXX" with "and that vulnerable function is actually reachable from an internet-facing endpoint in this specific deployment," which is where most vulnerability backlogs balloon into thousands of theoretically-critical, practically-irrelevant findings.
How Safeguard Helps
Safeguard sits on top of EKS, GKE, and AKS rather than replacing any provider's control-plane security — it closes the gap between "this CVE exists in an image" and "this CVE is actually exploitable in your cluster." Reachability analysis traces vulnerable functions and packages to the code paths your workloads actually execute, so a critical CVE in an unused library in a base image doesn't page your on-call team at 2 a.m. Griffin AI correlates that reachability signal with runtime context — network exposure, IAM/identity bindings, and the specific cloud's default posture (public EKS endpoint, unpatched AKS identity flow, non-Autopilot GKE node) — to rank what to fix first across a multi-cloud fleet. Safeguard generates and ingests SBOMs across all three registries (ECR, Artifact Registry, ACR) to give you one inventory instead of three, and where a fix is available, it opens an auto-fix pull request with the dependency bump or config change already scoped, so remediation doesn't wait on a manual audit of which cluster is running which identity model.