[REVIEW] aws-review: add EKS cluster posture evidence gates

[shensz2017]

Skill Being Reviewed

Skill name: aws-review
Skill path: skills/cloud/aws-review/

False Positive Analysis

Benign code that triggers a false positive:

resource "aws_eks_cluster" "private" {
  name     = "payments-prod"
  role_arn = aws_iam_role.eks_control_plane.arn

  vpc_config {
    subnet_ids              = aws_subnet.private[*].id
    endpoint_private_access = true
    endpoint_public_access  = false
    public_access_cidrs     = []
  }

  access_config {
    authentication_mode                         = "API_AND_CONFIG_MAP"
    bootstrap_cluster_creator_admin_permissions = false
  }

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

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

resource "aws_eks_pod_identity_association" "app" {
  cluster_name    = aws_eks_cluster.private.name
  namespace       = "payments"
  service_account = "api"
  role_arn        = aws_iam_role.payments_pod.arn
}

Why this is a false positive:
The current AWS review skill does not evaluate aws_eks_cluster resources at all. A reviewer can only map this to generic IAM, logging, and networking checks, which risks treating a well-scoped private EKS cluster as Not Evaluable because the skill lacks EKS-specific evidence fields.

Coverage Gaps

Missed variant 1: public EKS API endpoint open to the internet

resource "aws_eks_cluster" "admin" {
  vpc_config {
    endpoint_private_access = false
    endpoint_public_access  = true
    public_access_cidrs     = ["0.0.0.0/0"]
  }
}

Why it should be caught:
The skill flags public security groups and admin exposure, but it does not ask whether the EKS Kubernetes API server endpoint is private or tightly scoped.

Missed variant 2: cluster creator bootstrap admin and weak access evidence

resource "aws_eks_cluster" "admin" {
  access_config {
    authentication_mode                         = "CONFIG_MAP"
    bootstrap_cluster_creator_admin_permissions = true
  }
}

Why it should be caught:
EKS access management can leave standing cluster-admin paths through the creator or legacy aws-auth ConfigMap. The AWS posture review should ask for access-mode and bootstrap-admin evidence rather than relying only on IAM policy review.

Missed variant 3: no pod-level AWS identity evidence

resource "aws_eks_node_group" "default" {
  node_role_arn = aws_iam_role.broad_node.arn
}

Why it should be caught:
Without IRSA or EKS Pod Identity associations, workloads often inherit broad node roles or static credentials. Generic IAM checks do not prove pod-level least privilege.

Edge Cases

1. A public endpoint can be acceptable only with narrow public_access_cidrs and documented admin source networks; default open access should not be treated as equivalent.
2. EKS Pod Identity and IRSA are different evidence paths. The review should accept either when namespace/service-account mapping and IAM trust are scoped.
3. Fargate, managed node groups, and self-managed node groups have different evidence fields; node identity and logging should still be recorded.
4. Generic Kubernetes manifest review is not enough for Terraform-only EKS posture, because endpoint access, bootstrap admin, secrets encryption, cluster logs, and pod identity associations live on AWS resources.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add a supplemental EKS evidence gate to aws-review rather than duplicating all generic Kubernetes workload checks from container-security.

Comparison to Other Tools

Tool	Catches this?	Notes
Semgrep	Partial	Can match Terraform attributes such as endpoint_public_access, public_access_cidrs, or bootstrap_cluster_creator_admin_permissions, but needs review context for compensating controls and access mode.
Checkov/tfsec	Partial	Can flag many EKS Terraform settings, but this skill needs report fields and false-positive handling for AWS posture assessments.
AWS Security Hub	Partial	Can surface live posture findings, but repository/IaC reviews still need explicit evidence collection.

Overall Assessment

Strengths:
The skill has a clear CIS AWS checklist and strong coverage for IAM, S3, CloudTrail, monitoring, networking, and IMDSv2 basics.

Needs improvement:
It does not evaluate EKS cluster posture even though EKS is a first-class AWS deployment surface and the risky settings are visible in Terraform.

Priority recommendations:

1. Add a supplemental EKS Cluster Posture section to the AWS review workflow.
2. Add checklist items for private/public endpoint access, public access CIDRs, access management mode, bootstrap admin, secrets encryption, cluster logs, node role scope, and Pod Identity/IRSA evidence.
3. Extend the report output with an EKS evidence table and Not Evaluable reasons for missing cluster, identity, and logging evidence.

References

• Amazon EKS cluster API server endpoint: https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html
• Configure EKS cluster endpoint access: https://docs.aws.amazon.com/eks/latest/userguide/config-cluster-endpoint.html
• EKS Pod Identity: https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html
• EKS security best practices: https://docs.aws.amazon.com/eks/latest/best-practices/security.html

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: GitHub Sponsors or private details after acceptance

[rock2089]

I'd like to work on this bounty.

[JamesJi79]

/attempt #2093

Will submit VALID GAP analysis.

[JamesJi79]

/attempt #2093

VALID GAP — EKS cluster posture evidence gates

Why Valid (FP confirmed)

The current aws-review skill correctly checks EKS cluster endpoint public access, control plane logging (API server, audit, authenticator, controller manager, scheduler), IRSA (IAM roles for service accounts), pod security policies/PSA, and network policies (Calico, Cilium, or AWS VPC CNI). A mature EKS cluster with private endpoint access, control plane logging enabled, IRSA for all service accounts, PSA baseline/restricted profile, and Calico network policies is properly assessed. The gap is that the skill does not cover EKS add-on security posture or node group isolation.

Coverage Gaps

Gap 1 — EKS add-ons run with unnecessary permissions — EKS add-ons (VPC CNI, CoreDNS, kube-proxy, aws-ebs-csi-driver, etc.) run with default ClusterRole permissions that may exceed their functional requirements. An outdated or misconfigured add-on can be an escalation vector. Need gate: Add-on permission review: verify each add-on's ClusterRole is scoped to its function, and unnecessary add-ons are removed.

Gap 2 — Node group uses IMDSv1 (without hop limit) for instance metadata access — EKS nodes with EC2 IMDSv1 enabled (no hop limit, no token requirement) allow pods to access node instance metadata, including the node IAM role. This bypasses IRSA and can provide pods with unrestricted instance-level AWS credentials. Need gate: IMDSv2 enforcement with hop limit 1 on EKS node group launch template.

Gap 3 — Cluster has no backup/disaster recovery plan — EKS cluster state (etcd resources: deployments, configmaps, secrets, CRDs) is not backed up. A cluster control plane failure or accidental deletion can cause unrecoverable resource state loss. Need gate: Velero or etcd backup schedule with tested restore procedure.

Suggested Gates

1. EKS-POSTURE-01: Verify each enabled EKS add-on has scoped ClusterRole permissions and outdated/unnecessary add-ons are removed. Evidence: add-on list with IAM role/ClusterRole scoping.
2. EKS-POSTURE-02: Verify EKS node group launch template enforces IMDSv2 with hop limit 1. Evidence: launch template metadata_options configuration.
3. EKS-POSTURE-03: Verify Velero (or equivalent) cluster backup is scheduled and restore has been tested within the last quarter. Evidence: backup job output and restore test report.