AWS EKS Hardening

EKS Standard: Pass endpoint_public_access = false and endpoint_private_access = true at cluster creation. For required external access, scope public_access_cidrs to a CIDR allow-list. Most VPC config is immutable post-create. EKS Auto Mode: The same private-endpoint configuration is supported. Node management is automated, but control-plane endpoint configuration is identical to Standard mode.

Enable a private EKS cluster endpoint so the kube-apiserver is unreachable from the public internet. Combine with public_access_cidrs if external access is genuinely required (CI runners, admin VPNs). A public kube-apiserver is the number-one Kubernetes breach vector — any leaked kubeconfig credential is immediately usable from the internet without network-level barriers.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_eks_cluster" "hardened" {
  name     = "hardened-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.30"

  vpc_config {
    subnet_ids              = var.private_subnet_ids
    endpoint_public_access  = false
    endpoint_private_access = true
    # If public access is unavoidable, scope to a narrow allow-list:
    # public_access_cidrs   = [var.management_cidr]
  }

  access_config {
    authentication_mode                         = "API"
    bootstrap_cluster_creator_admin_permissions = false
  }

  enabled_cluster_log_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"]

  encryption_config {
    provider { key_arn = aws_kms_key.eks_secrets.arn }
    resources = ["secrets"]
  }
}

Remediation — aws eks

aws eks create-cluster \
  --name hardened-cluster \
  --role-arn arn:aws:iam::ACCOUNT:role/eks-cluster-role \
  --resources-vpc-config \
      endpointPublicAccess=false,endpointPrivateAccess=true,subnetIds=subnet-aaa,subnet-bbb \
  --access-config authenticationMode=API,bootstrapClusterCreatorAdminPermissions=false \
  --kubernetes-version 1.30

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EKS cluster with private-only API endpoint, KMS envelope encryption, and audit logs enabled.
Parameters:
  ClusterName:
    Type: String
  ClusterRoleArn:
    Type: String
  ClusterKmsKeyArn:
    Type: String
  SubnetIds:
    Type: List<AWS::EC2::Subnet::Id>
  SecurityGroupIds:
    Type: List<AWS::EC2::SecurityGroup::Id>
Resources:
  PrivateEksCluster:
    Type: AWS::EKS::Cluster
    Properties:
      Name: !Ref ClusterName
      Version: '1.31'
      RoleArn: !Ref ClusterRoleArn
      ResourcesVpcConfig:
        SubnetIds: !Ref SubnetIds
        SecurityGroupIds: !Ref SecurityGroupIds
        EndpointPublicAccess: false
        EndpointPrivateAccess: true
      EncryptionConfig:
        - Provider:
            KeyArn: !Ref ClusterKmsKeyArn
          Resources:
            - secrets
      Logging:
        ClusterLogging:
          EnabledTypes:
            - Type: api
            - Type: audit
            - Type: authenticator
            - Type: controllerManager
            - Type: scheduler

Remediation — AWS CDK (TypeScript)

import * as cdk from 'aws-cdk-lib';
import { aws_eks as eks, aws_ec2 as ec2, aws_iam as iam, aws_kms as kms } from 'aws-cdk-lib';
import { Construct } from 'constructs';

export interface PrivateEksProps extends cdk.StackProps {
  clusterName: string;
  vpc: ec2.IVpc;
  clusterKmsKeyArn: string;
}

export class PrivateEksClusterStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: PrivateEksProps) {
    super(scope, id, props);

    new eks.Cluster(this, 'PrivateCluster', {
      clusterName: props.clusterName,
      version: eks.KubernetesVersion.V1_31,
      vpc: props.vpc,
      vpcSubnets: [{ subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }],
      endpointAccess: eks.EndpointAccess.PRIVATE,
      secretsEncryptionKey: kms.Key.fromKeyArn(this, 'ClusterKmsKey', props.clusterKmsKeyArn),
      clusterLogging: [
        eks.ClusterLoggingTypes.API,
        eks.ClusterLoggingTypes.AUDIT,
        eks.ClusterLoggingTypes.AUTHENTICATOR,
        eks.ClusterLoggingTypes.CONTROLLER_MANAGER,
        eks.ClusterLoggingTypes.SCHEDULER,
      ],
    });
  }
}

Compliance mapping

fields @timestamp, eventName, requestParameters.name, requestParameters.resourcesVpcConfig.endpointPublicAccess, requestParameters.resourcesVpcConfig.publicAccessCidrs, userIdentity.arn, sourceIPAddress
          | filter eventSource = "eks.amazonaws.com" and eventName = "UpdateClusterConfig"
          | filter requestParameters.resourcesVpcConfig.endpointPublicAccess = true
          | sort @timestamp desc
          | limit 100

Equivalent controls in other providers: GKE private cluster + authorized networks, AKS private cluster, OKE private API endpoint.

EKS Standard: EKS Pod Identity (GA Nov 2023) is the recommended pattern for new clusters. Install the eks-pod-identity-agent managed add-on, then create aws_eks_pod_identity_association resources mapping K8s ServiceAccounts to IAM roles. EKS Auto Mode: The Pod Identity agent is pre-installed and managed by EKS Auto. Create associations the same way; no agent-DaemonSet management required.

Bind Kubernetes ServiceAccounts to AWS IAM Roles via EKS Pod Identity associations. Pod Identity eliminates the per-cluster OIDC provider, uses cluster-scoped associations (not per-pod annotations), and provides faster credential rotation than the legacy IRSA pattern. The default Node IAM role should be least-privilege and decoupled from per-workload AWS permissions; pod-scoped IAM is granted via Pod Identity associations.

Migration from IRSA: Existing IRSA workloads (which use the per-cluster OIDC provider plus the eks.amazonaws.com/role-arn ServiceAccount annotation) remain supported. IRSA is the legacy migration path; new clusters should adopt Pod Identity, and existing clusters can migrate workload-by-workload by creating a Pod Identity association and removing the IRSA annotation.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_iam_role" "app" {
  name = "eks-app-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "pods.eks.amazonaws.com" }
      Action = ["sts:AssumeRole", "sts:TagSession"]
    }]
  })
}

resource "aws_eks_pod_identity_association" "app" {
  cluster_name    = aws_eks_cluster.hardened.name
  namespace       = "production"
  service_account = "app-sa"
  role_arn        = aws_iam_role.app.arn
}

# Install the Pod Identity agent add-on (EKS Standard only — EKS Auto manages this)
resource "aws_eks_addon" "pod_identity_agent" {
  cluster_name = aws_eks_cluster.hardened.name
  addon_name   = "eks-pod-identity-agent"
}

Remediation — aws eks

aws eks create-addon \
  --cluster-name hardened-cluster \
  --addon-name eks-pod-identity-agent

aws eks create-pod-identity-association \
  --cluster-name hardened-cluster \
  --namespace production \
  --service-account app-sa \
  --role-arn arn:aws:iam::ACCOUNT:role/eks-app-role

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EKS Pod Identity association binding a Kubernetes service account to a least-priv IAM role.
Parameters:
  ClusterName:
    Type: String
  Namespace:
    Type: String
  ServiceAccount:
    Type: String
  PodRoleArn:
    Type: String
Resources:
  PodIdentityAssociation:
    Type: AWS::EKS::PodIdentityAssociation
    Properties:
      ClusterName: !Ref ClusterName
      Namespace: !Ref Namespace
      ServiceAccount: !Ref ServiceAccount
      RoleArn: !Ref PodRoleArn

Compliance mapping

fields @timestamp, eventName, requestParameters.clusterName, requestParameters.namespace, requestParameters.serviceAccount, requestParameters.roleArn, userIdentity.arn
          | filter eventSource = "eks.amazonaws.com" and eventName = "CreatePodIdentityAssociation"
          | parse requestParameters.roleArn /arn:aws:iam::(?<acct>\d+):role\/(?<role>.+)/
          | filter role like /Admin/ or role like /FullAccess/ or role = "OrganizationAccountAccessRole"
          | sort @timestamp desc
          | limit 50

Equivalent controls in other providers: GKE Workload Identity Federation, AKS Workload Identity, OKE Workload Identity.

EKS Standard: Envelope encryption is configured at cluster create time and is immutable for the lifetime of the cluster — choose the KMS customer-managed CMK before creation. Enable automatic CMK rotation on the key. EKS Auto Mode: Same configuration model. The customer manages CMK lifecycle (rotation, revocation, grants); EKS uses the CMK to encrypt the Data Encryption Key that wraps Kubernetes Secrets in etcd.

Enable envelope encryption for Kubernetes Secrets using a customer-managed KMS key (CMK). This adds a layer on top of AWS-managed at-rest encryption and gives the customer control over the key lifecycle. Without envelope encryption, AWS holds the encryption key for etcd; with envelope encryption, revoking the CMK (via KMS policy or key disable) makes Secrets unreadable cluster-wide.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_kms_key" "eks_secrets" {
  description             = "EKS envelope encryption CMK"
  enable_key_rotation     = true
  deletion_window_in_days = 30
}

resource "aws_kms_alias" "eks_secrets" {
  name          = "alias/eks-secrets"
  target_key_id = aws_kms_key.eks_secrets.key_id
}

resource "aws_eks_cluster" "hardened" {
  name = "hardened-cluster"
  # ... vpc_config, role_arn ...

  encryption_config {
    provider { key_arn = aws_kms_key.eks_secrets.arn }
    resources = ["secrets"]
  }
}

Remediation — aws eks

aws eks create-cluster \
  --name hardened-cluster \
  --role-arn arn:aws:iam::ACCOUNT:role/eks-cluster-role \
  --resources-vpc-config subnetIds=subnet-aaa,subnet-bbb,endpointPublicAccess=false,endpointPrivateAccess=true \
  --encryption-config '[{"provider":{"keyArn":"arn:aws:kms:REGION:ACCOUNT:key/KEY-UUID"},"resources":["secrets"]}]'

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS Config managed rule asserting every EKS cluster uses KMS envelope encryption for secrets.
Resources:
  EksSecretsEncryptedRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: eks-secrets-encrypted
      Source:
        Owner: AWS
        SourceIdentifier: EKS_SECRETS_ENCRYPTED
      Scope:
        ComplianceResourceTypes:
          - AWS::EKS::Cluster

Compliance mapping

fields @timestamp, eventName, requestParameters.keyId, requestParameters.pendingWindowInDays, userIdentity.arn, sourceIPAddress, errorCode
          | filter eventSource = "kms.amazonaws.com" and eventName in ["DisableKey","ScheduleKeyDeletion","PutKeyPolicy"]
          | filter requestParameters.keyId in ["alias/eks-envelope-prod","alias/eks-envelope-stage"]
          | sort @timestamp desc
          | limit 50

Equivalent controls in other providers: GKE Cloud KMS secrets encryption, AKS KMS etcd encryption, OKE Vault CMK secrets encryption.

EKS Standard: All five control-plane log types are off by default. Enable all five explicitly — api, audit, authenticator, controllerManager, scheduler — to CloudWatch Logs. Without the audit log, lateral movement via kubectl exec is invisible. EKS Auto Mode: Same five log types apply. Enable them in the cluster spec; EKS Auto delivers them to CloudWatch with the same retention and IAM controls.

Enable EKS control-plane logging (five log types) to CloudWatch Logs. The audit log is the most critical — it records every kube-apiserver request including the calling identity, verb, resource, and response code. CloudWatch Container Insights complements this with worker-node and pod-level telemetry and can be enabled as a Container Insights monitoring add-on.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_eks_cluster" "hardened" {
  name = "hardened-cluster"
  # ... role_arn, vpc_config ...

  enabled_cluster_log_types = [
    "api",
    "audit",
    "authenticator",
    "controllerManager",
    "scheduler"
  ]
}

resource "aws_cloudwatch_log_group" "eks" {
  name              = "/aws/eks/hardened-cluster/cluster"
  retention_in_days = 365
  kms_key_id        = aws_kms_key.logs.arn
}

Remediation — aws eks

aws eks update-cluster-config \
  --name hardened-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: CloudWatch Logs metric filter alarming on EKS audit log access-denied spikes.
Parameters:
  AuditLogGroupName:
    Type: String
  AlarmTopicArn:
    Type: String
Resources:
  AccessDeniedMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      LogGroupName: !Ref AuditLogGroupName
      FilterPattern: '{ $.responseStatus.code = 403 }'
      MetricTransformations:
        - MetricName: EksAuditAccessDenied
          MetricNamespace: Security/EKS
          MetricValue: '1'
  AccessDeniedAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: eks-audit-access-denied-spike
      MetricName: EksAuditAccessDenied
      Namespace: Security/EKS
      Statistic: Sum
      Period: 300
      EvaluationPeriods: 1
      Threshold: 20
      ComparisonOperator: GreaterThanThreshold
      AlarmActions:
        - !Ref AlarmTopicArn

Compliance mapping

fields @timestamp, eventName, requestParameters.name, requestParameters.logging.clusterLogging, userIdentity.arn, sourceIPAddress
          | filter eventSource = "eks.amazonaws.com" and eventName = "UpdateClusterConfig"
          | filter requestParameters.logging.clusterLogging.0.enabled = false or requestParameters.logging.clusterLogging.1.enabled = false
          | sort @timestamp desc
          | limit 100

Equivalent controls in other providers: GKE Cloud Audit Logs, AKS control-plane audit logs (diagnostic settings), OKE OCI Audit Logging.

EKS Standard: Managed node groups inherit IMDS settings from the launch template — set http_tokens = "required" and http_put_response_hop_limit = 1. Pods using EKS Pod Identity do not need IMDS access at all; the agent uses a Unix socket. EKS Auto Mode: IMDSv2 enforcement and hop-limit 1 are the default; verify with aws ec2 describe-instances --instance-ids i-... --query 'Reservations[].Instances[].MetadataOptions'.

Enforce IMDSv2 (http_tokens=required) and a hop-limit of 1 on all worker nodes. Hop-limit 1 prevents containerized workloads from reaching the IMDS endpoint at 169.254.169.254, which would otherwise grant the container the same node IAM role permissions as the host. The worker-node IAM role itself must be least-privilege (the AWS-managed AmazonEKSWorkerNodePolicy + AmazonEC2ContainerRegistryReadOnly + AmazonEKS_CNI_Policy attachments only — no application-level IAM grants).

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_launch_template" "nodes" {
  name_prefix   = "eks-nodes-"
  image_id      = data.aws_ssm_parameter.bottlerocket_ami.value
  instance_type = "m6i.large"

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"   # IMDSv2 only
    http_put_response_hop_limit = 1            # block from inside containers
    instance_metadata_tags      = "disabled"
  }
}

resource "aws_eks_node_group" "main" {
  cluster_name    = aws_eks_cluster.hardened.name
  node_group_name = "bottlerocket-ng"
  node_role_arn   = aws_iam_role.node.arn
  subnet_ids      = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.nodes.id
    version = aws_launch_template.nodes.latest_version
  }

  scaling_config { desired_size = 3; min_size = 3; max_size = 6 }
}

Remediation — aws ec2

# Enforce on a running instance (CI/diagnostic use; prefer launch-template config)
aws ec2 modify-instance-metadata-options \
  --instance-id i-0abc123 \
  --http-tokens required \
  --http-put-response-hop-limit 1 \
  --http-endpoint enabled

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EC2 launch template forcing IMDSv2 + hop-limit 2 for EKS managed node group instances.
Resources:
  NodeLaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateName: eks-node-imdsv2
      LaunchTemplateData:
        MetadataOptions:
          HttpEndpoint: enabled
          HttpTokens: required
          HttpPutResponseHopLimit: 2
          InstanceMetadataTags: enabled

Compliance mapping

fields @timestamp, eventName, requestParameters.instanceId, requestParameters.httpTokens, requestParameters.httpPutResponseHopLimit, userIdentity.arn
          | filter eventSource = "ec2.amazonaws.com" and eventName = "ModifyInstanceMetadataOptions"
          | filter requestParameters.httpTokens = "optional" or requestParameters.httpPutResponseHopLimit > 1
          | sort @timestamp desc
          | limit 100

Equivalent controls in other providers: GKE legacy metadata + ABAC disable, AKS IMDS NetworkPolicy block, OCI IAM least-privilege cluster access.

EKS Standard: Configure authentication_mode = "API" (Cluster Access Management API only) at cluster creation; use aws_eks_access_entry to map IAM principals to Kubernetes groups. A dedicated security group on worker nodes restricts ingress to the cluster security group only. EKS Auto Mode: The same access model applies; node security groups are managed by EKS Auto with a least-privilege baseline.

This control bundles two access-control concerns: (a) Cluster Access Management API access entries — the modern primary mechanism for mapping AWS IAM identities to Kubernetes RBAC — and (b) security-group segmentation between the EKS-managed control plane and worker nodes. The aws-auth ConfigMap is deprecated as the primary EKS access mechanism — new clusters MUST use Cluster Access Management API access entries via aws eks create-access-entry. The legacy aws-auth path remains supported for backward compatibility only, and the aws-auth ConfigMap is invisible to access-entry tooling.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_eks_cluster" "hardened" {
  name = "hardened-cluster"
  # ... role_arn, vpc_config ...

  access_config {
    authentication_mode                         = "API"   # NOT "API_AND_CONFIG_MAP"
    bootstrap_cluster_creator_admin_permissions = false
  }
}

resource "aws_eks_access_entry" "admin" {
  cluster_name  = aws_eks_cluster.hardened.name
  principal_arn = aws_iam_role.cluster_admin.arn
  type          = "STANDARD"
}

resource "aws_eks_access_policy_association" "admin" {
  cluster_name  = aws_eks_cluster.hardened.name
  principal_arn = aws_iam_role.cluster_admin.arn
  policy_arn    = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
  access_scope { type = "cluster" }
}

resource "aws_security_group" "nodes" {
  name        = "eks-nodes-sg"
  description = "EKS worker node SG"
  vpc_id      = var.vpc_id
}

resource "aws_security_group_rule" "nodes_from_cluster" {
  type                     = "ingress"
  from_port                = 0
  to_port                  = 65535
  protocol                 = "tcp"
  security_group_id        = aws_security_group.nodes.id
  source_security_group_id = aws_eks_cluster.hardened.vpc_config[0].cluster_security_group_id
}

Remediation — aws eks

aws eks create-access-entry \
  --cluster-name hardened-cluster \
  --principal-arn arn:aws:iam::ACCOUNT:role/ClusterAdmin \
  --type STANDARD

aws eks associate-access-policy \
  --cluster-name hardened-cluster \
  --principal-arn arn:aws:iam::ACCOUNT:role/ClusterAdmin \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EKS node security group permitting only cluster-SG ingress on the kubelet port range.
Parameters:
  VpcId:
    Type: AWS::EC2::VPC::Id
  ClusterSecurityGroupId:
    Type: AWS::EC2::SecurityGroup::Id
Resources:
  NodeSg:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: eks-node-sg
      GroupDescription: Node SG — cluster control-plane SG only.
      VpcId: !Ref VpcId
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 10250
          ToPort: 10250
          SourceSecurityGroupId: !Ref ClusterSecurityGroupId
        - IpProtocol: tcp
          FromPort: 1025
          ToPort: 65535
          SourceSecurityGroupId: !Ref ClusterSecurityGroupId

Compliance mapping

fields @timestamp, eventName, requestParameters.principalArn, requestParameters.accessPolicyArn, requestParameters.clusterName, userIdentity.arn
          | filter eventSource = "eks.amazonaws.com" and eventName in ["CreateAccessEntry","AssociateAccessPolicy","UpdateAccessEntry"]
          | filter requestParameters.accessPolicyArn like /AmazonEKSClusterAdminPolicy/
          | sort @timestamp desc
          | limit 50

Equivalent controls in other providers: GKE control-plane access (private cluster + authorized networks), AKS Entra ID + Azure RBAC, OCI IAM least-privilege cluster access.

EKS Standard: Select BOTTLEROCKET_x86_64 (or BOTTLEROCKET_ARM_64) or AL2023_x86_64_STANDARD as the managed node group ami_type. Amazon Linux 2 (AL2) reached end-of-life in November 2025 — migrate to Bottlerocket or AL2023. EKS Auto Mode: Bottlerocket is the only node OS in EKS Auto — there is no AL2 or AL2023 choice to make; the OS is managed and continually patched by EKS Auto.

Use Bottlerocket (immutable container-optimized OS, read-only root filesystem, atomic image-based updates, SELinux-enforced) or AL2023 (Amazon Linux 2023) as the worker-node operating system. Amazon Linux 2 EKS-optimized AMIs reached end-of-life in November 2025; clusters still running AL2 nodes do not receive kernel security patches. When migrating from Amazon Linux 2, the choice is between AL2023 (incremental upgrade path, same package ecosystem) and Bottlerocket (security-focused redesign with no SSH by default and no general-purpose package manager) — Bottlerocket is the recommended choice for new clusters.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
data "aws_ssm_parameter" "bottlerocket_ami" {
  name = "/aws/service/bottlerocket/aws-k8s-1.30/x86_64/latest/image_id"
}

resource "aws_launch_template" "bottlerocket" {
  name_prefix   = "eks-bottlerocket-"
  image_id      = data.aws_ssm_parameter.bottlerocket_ami.value
  instance_type = "m6i.large"

  metadata_options {
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

resource "aws_eks_node_group" "bottlerocket" {
  cluster_name    = aws_eks_cluster.hardened.name
  node_group_name = "bottlerocket-ng"
  node_role_arn   = aws_iam_role.node.arn
  subnet_ids      = var.private_subnet_ids
  ami_type        = "BOTTLEROCKET_x86_64"

  launch_template {
    id      = aws_launch_template.bottlerocket.id
    version = aws_launch_template.bottlerocket.latest_version
  }

  scaling_config { desired_size = 3; min_size = 3; max_size = 6 }
}

Remediation — aws eks

aws eks create-nodegroup \
  --cluster-name hardened-cluster \
  --nodegroup-name bottlerocket-ng \
  --ami-type BOTTLEROCKET_x86_64 \
  --node-role arn:aws:iam::ACCOUNT:role/eks-node-role \
  --subnets subnet-aaa subnet-bbb \
  --scaling-config minSize=3,maxSize=6,desiredSize=3 \
  --launch-template id=lt-0abc,version='$Latest'

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EKS managed node group on Bottlerocket AMI with IMDSv2 launch template.
Parameters:
  ClusterName:
    Type: String
  NodeRoleArn:
    Type: String
  SubnetIds:
    Type: List<AWS::EC2::Subnet::Id>
  LaunchTemplateId:
    Type: String
Resources:
  BottlerocketNodeGroup:
    Type: AWS::EKS::Nodegroup
    Properties:
      ClusterName: !Ref ClusterName
      NodegroupName: bottlerocket-ng
      NodeRole: !Ref NodeRoleArn
      Subnets: !Ref SubnetIds
      AmiType: BOTTLEROCKET_x86_64
      ScalingConfig:
        MinSize: 2
        DesiredSize: 3
        MaxSize: 6
      LaunchTemplate:
        Id: !Ref LaunchTemplateId
        Version: '1'

Compliance mapping

fields @timestamp, eventName, requestParameters.nodegroupName, requestParameters.amiType, requestParameters.releaseVersion, userIdentity.arn
          | filter eventSource = "eks.amazonaws.com" and eventName in ["CreateNodegroup","UpdateNodegroupVersion"]
          | filter requestParameters.amiType != "BOTTLEROCKET_x86_64" and requestParameters.amiType != "BOTTLEROCKET_ARM_64"
          | sort @timestamp desc
          | limit 100

Equivalent controls in other providers: GKE Shielded Nodes (closest hardened-OS analog), OKE Oracle Linux 8 node OS hardening parallel.

EKS Standard: The PodSecurity admission controller is built into the kube-apiserver since Kubernetes 1.23. Apply namespace labels — pod-security.kubernetes.io/enforce: restricted — to block privileged pods. No add-on required. EKS Auto Mode: Same built-in admission controller. EKS Auto does not add a separate enforcement layer; namespace labels are the contract.

Enforce Pod Security Standards at the namespace level using the built-in PodSecurity admission controller. Target restricted for application namespaces (blocks privileged, hostNetwork, hostPath, runAsRoot, capabilities beyond NET_BIND_SERVICE); use baseline as the floor for legacy workloads during migration; reserve privileged for kube-system with a documented justification. The pre-1.25 admission mechanism that PSS replaces was removed from Kubernetes — do not attempt to reintroduce it on EKS.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
# Namespace PSS labels via hashicorp/kubernetes ~> 3.0 provider
resource "kubernetes_namespace" "production" {
  metadata {
    name = "production"
    labels = {
      "pod-security.kubernetes.io/enforce"         = "restricted"
      "pod-security.kubernetes.io/enforce-version" = "latest"
      "pod-security.kubernetes.io/audit"           = "restricted"
      "pod-security.kubernetes.io/warn"            = "restricted"
    }
  }
}

Remediation — kubectl

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Or as a YAML manifest:
cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
EOF

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS Config custom rule wrapping a Lambda evaluator for Pod Security Standards drift on EKS namespaces.
Parameters:
  EvaluatorFunctionArn:
    Type: String
Resources:
  PssEvaluatorRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: eks-pod-security-standards-baseline
      Description: Custom evaluator flagging EKS namespaces without pod-security.kubernetes.io/enforce=baseline.
      Source:
        Owner: CUSTOM_LAMBDA
        SourceIdentifier: !Ref EvaluatorFunctionArn
        SourceDetails:
          - EventSource: aws.config
            MessageType: ScheduledNotification
            MaximumExecutionFrequency: TwentyFour_Hours

Compliance mapping

fields @timestamp, user.username, verb, objectRef.namespace, requestObject.metadata.labels, responseStatus.code
          | filter verb in ["create","patch","update"] and objectRef.resource = "namespaces"
          | filter requestObject.metadata.labels.pod-security_kubernetes_io_enforce = "privileged"
          | sort @timestamp desc
          | limit 50

Equivalent controls in other providers: GKE PSS namespace labels, AKS Azure Policy PSS initiative, OKE PSS admission.

EKS Standard: Enable VPC CNI network policy by setting ENABLE_NETWORK_POLICY=true on the vpc-cni managed add-on (GA 2024), or install Calico as the policy enforcer. Without a NetworkPolicy-capable CNI, NetworkPolicy objects have no effect (silent failure). EKS Auto Mode: The VPC CNI with network policy enforcement is configured by EKS Auto; default-deny NetworkPolicy manifests are honored without additional CNI bootstrapping.

Apply a default-deny NetworkPolicy in every application namespace, then add explicit allow rules for required ingress and egress. Without a default-deny baseline, pod-to-pod and pod-to-external traffic is unrestricted by default, allowing any compromised pod to scan the pod subnet and reach internal services freely.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_eks_addon" "vpc_cni" {
  cluster_name = aws_eks_cluster.hardened.name
  addon_name   = "vpc-cni"

  configuration_values = jsonencode({
    enableNetworkPolicy = "true"
  })
}

# Default-deny NetworkPolicy via hashicorp/kubernetes ~> 3.0
resource "kubernetes_manifest" "default_deny" {
  manifest = {
    apiVersion = "networking.k8s.io/v1"
    kind       = "NetworkPolicy"
    metadata = {
      name      = "default-deny-all"
      namespace = "production"
    }
    spec = {
      podSelector = {}
      policyTypes = ["Ingress", "Egress"]
    }
  }
}

Remediation — kubectl

cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
EOF

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EKS managed VPC CNI addon configured with enableNetworkPolicy=true for K8s NetworkPolicy enforcement.
Parameters:
  ClusterName:
    Type: String
Resources:
  VpcCniAddon:
    Type: AWS::EKS::Addon
    Properties:
      ClusterName: !Ref ClusterName
      AddonName: vpc-cni
      ResolveConflicts: OVERWRITE
      ConfigurationValues: !Sub |
        {
          "enableNetworkPolicy": "true"
        }

Compliance mapping

fields @timestamp, user.username, verb, objectRef.namespace, objectRef.name, requestObject.spec.policyTypes
          | filter objectRef.resource = "networkpolicies"
          | filter verb in ["delete","update","patch"]
          | filter objectRef.name like /default-deny/
          | sort @timestamp desc
          | limit 100

Equivalent controls in other providers: GKE Dataplane V2 NetworkPolicy, AKS Azure CNI NetworkPolicy, OKE Calico NetworkPolicy.

EKS Standard: Use the EKS-managed add-on lifecycle for vpc-cni, kube-proxy, coredns — plus optionally aws-ebs-csi-driver, eks-pod-identity-agent, amazon-cloudwatch-observability. Managed add-ons receive AWS-signed versions and integrate with the cluster upgrade flow. EKS Auto Mode: Add-on lifecycle is managed by EKS Auto — manual version selection is unnecessary; AWS schedules upgrades aligned to the K8s control-plane version.

Use EKS-managed add-ons for the three core networking and DNS components (vpc-cni, kube-proxy, coredns). Managed add-ons receive AWS-signed versions, security patches via the EKS control-plane upgrade flow, and conflict resolution. Self-managed add-on installation (e.g. raw kubectl apply of community manifests) skips signature verification, version compatibility checks against the control-plane Kubernetes version, and the upgrade orchestration.

Remediation — Terraform

# Terraform AWS provider ~> 5.0
resource "aws_eks_addon" "vpc_cni" {
  cluster_name                = aws_eks_cluster.hardened.name
  addon_name                  = "vpc-cni"
  resolve_conflicts_on_update = "OVERWRITE"
  configuration_values        = jsonencode({ enableNetworkPolicy = "true" })
}

resource "aws_eks_addon" "kube_proxy" {
  cluster_name                = aws_eks_cluster.hardened.name
  addon_name                  = "kube-proxy"
  resolve_conflicts_on_update = "OVERWRITE"
}

resource "aws_eks_addon" "coredns" {
  cluster_name                = aws_eks_cluster.hardened.name
  addon_name                  = "coredns"
  resolve_conflicts_on_update = "OVERWRITE"
}

Remediation — aws eks

VPC_CNI_VERSION=$(aws eks describe-addon-versions \
  --addon-name vpc-cni \
  --kubernetes-version 1.30 \
  --query 'addons[0].addonVersions[0].addonVersion' --output text)

aws eks create-addon \
  --cluster-name hardened-cluster \
  --addon-name vpc-cni \
  --addon-version "$VPC_CNI_VERSION" \
  --resolve-conflicts OVERWRITE \
  --configuration-values '{"enableNetworkPolicy":"true"}'

Remediation — CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Description: EKS managed addons pinned to current versions for predictable upgrade cadence.
Parameters:
  ClusterName:
    Type: String
Resources:
  CoreDnsAddon:
    Type: AWS::EKS::Addon
    Properties:
      ClusterName: !Ref ClusterName
      AddonName: coredns
      ResolveConflicts: OVERWRITE
  KubeProxyAddon:
    Type: AWS::EKS::Addon
    Properties:
      ClusterName: !Ref ClusterName
      AddonName: kube-proxy
      ResolveConflicts: OVERWRITE
  EbsCsiAddon:
    Type: AWS::EKS::Addon
    Properties:
      ClusterName: !Ref ClusterName
      AddonName: aws-ebs-csi-driver
      ResolveConflicts: OVERWRITE

Compliance mapping

fields @timestamp, eventName, requestParameters.clusterName, requestParameters.addonName, requestParameters.addonVersion, requestParameters.resolveConflicts, userIdentity.arn
          | filter eventSource = "eks.amazonaws.com" and eventName in ["DeleteAddon","UpdateAddon"]
          | filter requestParameters.addonName in ["vpc-cni","kube-proxy","coredns","aws-ebs-csi-driver","aws-efs-csi-driver"]
          | sort @timestamp desc
          | limit 100

Equivalent controls in other providers: OKE Enhanced Cluster add-on lifecycle (closest 1:1).