Private Subnets

[super-cob]

Some orgs have security requirements to only have EC2 running in private subnets. Can we make this some kind of option for this terraform deployment?

[salvis2]

I actually have found the option necessary to make that happen. My local work isn't synced to the development here because of different nodegroup options, but just this morning I pushed my work to a new branch unmanaged_nodegroups.

In that branch, the bits of note are mostly here. Basically, you need the following in the vpc module block:

module "vpc" {
  ...

  private_subnets = [something]

  enable_dns_hostnames = true
  enable_dns_support   = true
  enable_nat_gateway   = true
  single_nat_gateway   = true

  private_subnet_tags = {
    "kubernetes.io/cluster/${var.cluster_name}" = "shared"
    "kubernetes.io/role/internal-elb"           = "1"
  }
}

and the following in the eks module block:

module "eks" {
  ...
  subnets = module.vpc.private_subnets
  cluster_endpoint_private_access = true
  ...
}

The use of single_nat_gateway is really just helpful because an AWS account only gets 5 IP addresses, I think, so you can use just one instead of three (one for each subnet). I have a working cluster configuration with this.

Terraform should have the capability to allow us to dynamically set up public / private subnet usage for the modules based on an input variable. Is that what you are thinking of having?

[yuvipanda]

Managed nodegroups also just got the ability to be in private subnets.

[jaytmiller]

STScI is still very interested in this topic, but before we run off and start coding, I wanted to double check the status of the unmanaged_nodegroups branch. Is there a plan to merge that anytime soon? If not, can you suggest an approach for us which would avoid/minimize conflicts with your branch when unmanaged_nodegroups does merge? If possible we'd like to contribute back, maybe we could do the input variable handling to make private subnets optional?

[salvis2]

@jaytmiller So I think since the main branch and unmanaged_nodegroups specifically have managed vs unmanaged nodegroups, they wouldn't really be in the same branch. I could see them being parallel, but separate, because of these two different use cases. Managed nodegroups (I hear) usually lag behind in terms of features.

That said, we could try to configure an option to opt in or out of having the nodegroup being managed. This might be easier if we turn this repo into a Terraform module, which is a whole other can of worms.

I can definitely take some time next week to examine unmanaged_nodegroups and see what should be done. I think it contained my development work while making some hackweek infrastructure but that now lives in hackweek-template-infrastructure. We could move the relevant work into the main branch and delete unmanaged_nodegroups. What are your thoughts? Happy to collaborate here.