The same Kubernetes, different responsibilities
Kubernetes has strong security building blocks wherever it runs: TLS between components, role-based access control (RBAC), admission control, network policies, audit logging and encryption at rest for API data. A well-run self-managed cluster can use all of them. The real difference between Amazon EKS and self-managed Kubernetes on Amazon EC2 is not which features exist, but who operates and secures each layer, and how much effort it takes to get the defaults right.
The shared responsibility model
AWS describes EKS security through the shared responsibility model: AWS is responsible for security of the cloud, and you for security in the cloud.
- On EKS, AWS runs and secures the Kubernetes control plane: the API server instances, etcd, and the infrastructure under them. You remain responsible for the data plane (unless you use EKS Auto Mode or Fargate), IAM and RBAC configuration, network design, workload security and your data.
- With EKS Auto Mode, AWS takes on more, including the lifecycle, patching and configuration of the EC2 instances it launches, according to the Auto Mode documentation.
- Self-managed, you own everything above the EC2 hypervisor: control plane hosts, etcd, certificates, the operating system, Kubernetes components and their upgrades.
Control plane security
On EKS, the control plane runs in an AWS-managed account, separate from your workloads, across multiple Availability Zones. You cannot reach etcd directly, and AWS handles the certificates, component configuration and patching of the control plane. You choose whether the API server endpoint is public, private or both, and can restrict public access to specific CIDR ranges.
Self-managed, those tasks are yours: protecting etcd with TLS and access controls, rotating certificates before they expire, hardening API server flags, keeping control plane hosts off the internet and patched, and backing up etcd. Tools like kubeadm help, and benchmarks such as the CIS Kubernetes Benchmark give you a checklist, but the ongoing work does not go away.
Authentication
Kubernetes does not manage user accounts itself; it relies on an external authenticator.
- EKS authenticates with AWS IAM. Access entries, managed through the EKS API, map IAM roles or users to Kubernetes permissions. This means human access can come from your existing identity provider through IAM Identity Center or IAM federation, with short-term credentials, MFA and AWS CloudTrail records. EKS also supports an external OIDC identity provider for user authentication if you prefer one.
- Self-managed clusters typically use client certificates, which are hard to revoke, or an OIDC identity provider configured on the API server. Running the AWS IAM Authenticator yourself is possible, but you install and operate it.
For workloads that call AWS APIs, EKS offers EKS Pod Identity and IAM roles for service accounts (IRSA), which give each service account its own IAM role and temporary credentials. On a self-managed cluster you can build IRSA-style federation yourself by publishing your service account issuer as an OIDC provider, but it is extra work to set up and maintain.
Authorization with RBAC
RBAC works the same in both models: Roles, ClusterRoles and their bindings decide what an authenticated identity can do. On EKS you can bind Kubernetes groups to access entries, or use AWS-managed access policies such as AmazonEKSViewPolicy and AmazonEKSClusterAdminPolicy, optionally scoped to namespaces. In either model, the common mistakes are the same: too many cluster-admin bindings, wildcard permissions and broad access to Secrets.
Network security
By default, every Pod can talk to every other Pod. Network policies change that, and both models support them through the CNI plugin:
- On EKS, the Amazon VPC CNI plugin can enforce Kubernetes network policies on EC2 Linux nodes, and you can also use security groups for Pods to control access to AWS resources.
- Self-managed clusters use whichever CNI you install, such as Calico or Cilium, which can also be installed on EKS.
In both cases, nodes and Pods live in your VPC, so subnet design, security groups, VPC endpoints and egress control are your responsibility.
Encryption of secrets and API data
Kubernetes supports encrypting API data at rest through a KMS provider, but on a self-managed cluster you configure the encryption provider, run the KMS plugin and manage keys yourself. If you skip it, Secrets are stored in etcd only base64-encoded.
On EKS, all Kubernetes API data is envelope encrypted by default on clusters running Kubernetes 1.28 or later, using KMS v2 with an AWS owned key. You can bring your own AWS KMS customer managed key if you need control over key policy and rotation. Remember that disabling or deleting that key will break the cluster, so protect it with tight key policies.
Patching and upgrades
Security patches arrive at three layers:
- Control plane. EKS patches it for you, including security patches for versions in standard and extended support. Self-managed, you patch it.
- Nodes. With managed node groups you trigger updates to new EKS-optimized AMIs; EKS Auto Mode replaces nodes automatically with a maximum node lifetime of 21 days; Fargate patches the underlying infrastructure. Self-managed, you build and roll images yourself.
- Kubernetes minor versions. Both models need regular upgrades. EKS gives each version 14 months of standard support plus 12 months of extended support, then upgrades the control plane automatically. Self-managed clusters on unsupported versions simply stop getting fixes.
Audit logging and detection
Kubernetes audit logs record who did what through the API. On EKS you enable control plane logging per log type (api, audit, authenticator, controllerManager, scheduler), and EKS delivers them to Amazon CloudWatch Logs. They are off by default, so turn on at least audit and authenticator. Separately, Amazon GuardDuty EKS Protection analyzes EKS audit log events for threats through its own stream, without requiring you to enable control plane logging. Self-managed, you write the audit policy, configure log backends and ship the logs yourself.
What you own in each model
| Area | Amazon EKS | Self-managed Kubernetes |
|---|---|---|
| Control plane and etcd | AWS | You |
| Control plane patching | AWS | You |
| Node OS and patching | You (AWS with Auto Mode or Fargate) | You |
| Authentication | IAM and access entries, or OIDC | You choose and operate it |
| RBAC and admission policy | You | You |
| Network policies | You (VPC CNI or another CNI) | You (your CNI) |
| Encryption of API data | On by default (1.28+) | You configure it |
| Audit logs | You enable; AWS delivers | You configure and ship |
| Workloads, images and data | You | You |
Neither model secures your workloads for you. Image scanning, Pod Security Admission, least-privilege RBAC and network policies are your job either way. EKS removes the control plane work and gives you safer defaults, which for most teams frees time to spend on those workload controls.
9Acts is an AWS Advanced Tier Services Partner and AWS MSP Partner and holds the AWS Level 1 MSSP Competency. If you want a review of your Kubernetes security posture, see our Kubernetes solutions or contact us.