Skip to content

EKS Capability support #3606

@jgsuess

Description

@jgsuess

Is your request related to a new offering from AWS?

Yes ✅ — Amazon EKS Capabilities was announced GA on November 30, 2025. At launch, capabilities include Argo CD, AWS Controllers for Kubernetes (ACK), and Kube Resource Orchestrator (KRO), and are created/managed via new EKS APIs such as CreateCapability. [aws.amazon.com], [aws.amazon.com], [docs.aws.amazon.com]

Is this functionality available in the AWS provider for Terraform?

As of the latest AWS provider releases (v6.22.x/v6.23.0 development) and the Terraform Registry docs for aws_eks_cluster, there is no documented support for creating or managing EKS Capabilities (e.g., no resource/data source for aws_eks_capability or arguments on aws_eks_cluster that map to the EKS Capabilities APIs). [github.com], [github.com], [registry.t...rraform.io]

Request: Please add first-class support for EKS Capabilities in the AWS provider. If support already exists in an unreleased or undocumented version, kindly reference the version and usage examples.


Is your request related to a problem? Please describe.

EKS Capabilities are managed, Kubernetes‑native platform features operated by AWS outside the cluster (e.g., Argo CD, ACK, KRO). They are enabled and configured via new EKS API operations (like CreateCapability) and corresponding user‑guide workflows. Without Terraform support, platform teams cannot declare these capabilities as code alongside their EKS clusters, leading to:

  • Operational drift between environments (dev/stage/prod) because capabilities must be enabled via console/CLI/eksctl. [docs.aws.amazon.com], [docs.aws.amazon.com]
  • Incomplete IaC coverage for EKS: clusters, node pools, and add‑ons are codified, but capabilities are not. [registry.t...rraform.io]
  • Complex, error‑prone bootstrapping when trying to layer GitOps (Argo CD), AWS resource management (ACK), or composition/orchestration (KRO) in a reproducible way across regions/accounts. [aws.amazon.com]

Describe the solution you'd like.

Add native Terraform resources and data sources to manage EKS Capabilities end‑to‑end:

  1. New resource: aws_eks_capability

    • Arguments:
      • cluster_name (string)
      • type (enum: ARGOCD, ACK, KRO) — aligned with EKS API valid types. [docs.aws.amazon.com]
      • capability_name (string)
      • role_arn (IAM Capability Role for the managed capability). [docs.aws.amazon.com]
      • delete_propagation_policy (e.g., RETAIN) — matches EKS API behavior when deleting a capability. [docs.aws.amazon.com]
      • configuration blocks that mirror the EKS API’s per‑type config:
    • Attributes:
  2. Data source: aws_eks_capability

    • Read capability details by cluster_name + capability_name/type.
  3. Provider‑level examples demonstrating:

    • Enabling Argo CD with IAM Identity Center integration and private network access via VPC endpoints. [docs.aws.amazon.com]
    • Enabling ACK with a least‑privilege IAM Capability Role to manage specific AWS services (e.g., S3, SQS) and multi‑account patterns. [docs.aws.amazon.com]
    • Enabling KRO and applying a sample composition to provision app bundles.
  4. Import support to adopt capabilities created outside Terraform (console/CLI/eksctl). [docs.aws.amazon.com]

This design maps cleanly to the official EKS Capabilities API and user guide, ensuring feature parity and a consistent Terraform experience. [docs.aws.amazon.com], [docs.aws.amazon.com]


Describe alternatives you've considered.

  • AWS CLI / eksctl: You can script CreateCapability outside Terraform, but this splits orchestration across tools and increases drift risk. [docs.aws.amazon.com]
  • Kubernetes‑only installs (in‑cluster): Traditional Helm/CRD installs of Argo CD/ACK/KRO miss the managed, out‑of‑cluster operational model EKS Capabilities provide (AWS‑operated scaling/patching/upgrades), which is the core value of the new offering. [aws.amazon.com]
  • Terraform external provisioners/local‑exec: Possible but brittle; difficult to model lifecycle, idempotency, and state for capabilities without provider‑native resources. (No direct doc, but limitation inferred from provider/state model.)
  • Third‑party modules: Current community EKS modules (e.g., terraform-aws-modules/terraform-aws-eks) expose EKS cluster features (including Auto Mode), but do not yet abstract EKS Capabilities; they would also rely on provider‑level support. [github.com], [registry.t...rraform.io]

Additional context

  • AWS announcement & user guide clearly position EKS Capabilities as GA and recommend using EKS API/CLI/eksctl/Console to enable them on new or existing clusters. Terraform support will let customers adopt capabilities consistently across environments and CI/CD. [aws.amazon.com], [docs.aws.amazon.com]
  • Security & IAM: The IAM Capability Role is admin‑scoped for ACK and must be carefully controlled; provider examples should include least‑privilege role templates and warnings. [docs.aws.amazon.com]
  • API coverage: Besides CreateCapability, the provider will likely need to wrap list/get/delete operations for lifecycle management and support delete_propagation_policy semantics. [docs.aws.amazon.com]
  • Docs to cite in provider examples:

Links:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions