Eksctl: Support for Fn::ImportValue or reference value from existing CloudFormation stack in the cluster config file

[neelakansha85]

Why do you want this feature?
eksctl allows us to specify an existing VPC in the config file, however its values need to be statically assigned and can not be referenced dynamically from another CloudFormation stack which manages VPC and output's all required values. This will help allowing manage network and other VPC related resources in a separate network stack without having to manually change the static values when their value changes or need to use similar config files for multiple AWS Accounts. This helps create cross-stack reference that CloudFormation already supports.

What feature/behavior/change do you want?
Support for using Fn::ImportValue function or similar templating options to allow passing values to it in underlying CloudFormation template. Something like few options below:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: test-eks-1
  region: us-east-1

vpc: 
  id: 
    Fn::ImportValue: "test-network-stack-us-east-1-vpc-VPCID"
  cidr: !ImportValue "test-network-stack-us-east-1-vpc-VPCCIDR"
  subnets:
    private:
      us-east-1a:
        id: 
          Fn::ImportValue: "test-network-stack-us-east-1-vpc-PrivateSubnet1ID"
        cidr: !ImportValue: "test-network-stack-us-east-1-vpc-PrivateSubnet1CIDR"
      us-east-1b:
        id:
          Fn::ImportValue: "test-network-stack-us-east-1-vpc-PrivateSubnet2ID"
        cidr: !ImportValue: "test-network-stack-us-east-1-vpc-PrivateSubnet2CIDR"

[neelakansha85]

Adding additional context here based on some discussions we had in Weave Community Slack regarding this.

The current behavior of eksctl supports below situations:

1. EKS related resources need to be setup in it's own VPC with default configuration provided by eksctl without any custom modifications to the VPC. This is a legit use case for many situations and makes a setting up EKS cluster much more easier than having to manage custom CloudFormation templates.
2. Supports setting up EKS related resources in an existing VPC which is managed outside of eksctl stack created in any form (such as AWS Console, CloudFormation or Terraform, etc.) However, this approach requires providing static values of the VPC ID, VPC CIDR, Subnet ID and Subnet CIDR in the config file.

This creates a lot of overhead in managing the infrastructure for large organizations with either multiple VPCs with custom configurations and/or multiple AWS Accounts based on different services or environments to be able to manage EKS cluster using eksctl. It also is prone to human error while adding static values to multiple config files and increases manual dependency during a disaster recovery situation while trying to bring all infrastructure up using automation.

A few approaches to consider or may be able to support existing VPC configs is by decoupling VPC related information from eksctl and importing or finding values dynamically using methods such as:

1. Support Fn::ImportValue or some kind of templating to allow passing value to this which is native to CloudFormation and can be used to pull references to these values from other CloudFormation Stacks already used to manage existing VPC.
2. Support importing values from AWS Systems Manager Parameter Store or similar external source where these values can be pushed or updated during an output of other tools managing those resources.
3. Use AWS Tags to identify VPC, Subnets and other resources based on the their tags value passed to eksctl config file for looking up VPC and Subnets. This provides flexibility of managing the VPC and related resources using any tool of choice such as CloudFormation, Terraform etc without tying it to one and eksctl can still continue managing the cluster resources.

[pierresteiner]

This would help a lot ! +1

[inductor]

+1

I'd really love this!

[whereisaaron]

Fn::ImportValue or equivalent would help a lot with managing eksctl clusters as there is so much that has to be hard-coded in the config file right now, and sometimes repeated in a dozen places (for each node group); subnets, security groups, polices, target groups, etc.

[neelakansha85]

Checking to see if there is any timeline on this feature?

[opsroller]

This is a terrible idea, once you have an export imported in another stack, the stack with the export is no longer able to perform updates and becomes locked.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.