Add additional security rule to existing cluster group with condition based on rule to allow internal vpc access (eg. from vpn/bastion), for example:
If var.cluster_create_security_group && var.cluster_endpoint_private_access is true && var.cluster_api_access_groups > 0, create the rule with the array of groups to allow 443 access to cluster
It doesn't allow this, instead i have to create new group from scratch with all the worker node rules and pass to the module.
In production, the control plane should be private so it would be nice to make it easier to achieve this.
when deploying eks cluster i just pass something like this:
module "eks" {
..
cluster_api_access_groups = [module.bastion.bastion_security_group_id, module.jenkins.jenkins_security_group_id]
..
}
and it just adds this secruty group ids to the cluster security group
I haven't submitted a pr but happy to do so if this gets approved
So EKS supports the adding of additional security groups upon creation of the cluster. They don't have support for changing them yet.
I've imported a cluster that has this configuration, but terraform wants to replace the cluster, as this module doesn't have support for additional security groups yet.

When ever do a plan i get the following:
~ vpc_config {
~ cluster_security_group_id = "sg-12345678" -> (known after apply)
endpoint_private_access = true
endpoint_public_access = true
~ security_group_ids = [
- "sg-87654321",
] -> (known after apply) # forces replacement
subnet_ids = [
"sg-12345678"
]
~ vpc_id = "vpc-12345678" -> (known after apply)
}
I will be unable to successfully import this cluster to terraform until this is fixed.
@smcaine I believe that my issue would be resolved by this issue, thats why i'm adding this info as a comment here. I can help with any code changes if necessary
Also, looking at the terraform docs, aws_eks_cluster already expects a list for the vpc_config.security_group_ids. I'm guessing the first element, element[0], is the cluster security group, and additional ones are considered additional security groups.
I arrived here because I was looking into changes for the AWS announcement - https://aws.amazon.com/about-aws/whats-new/2019/12/dns-resolution-for-eks-clusters-using-private-endpoints/. If you have followed the defaults up to this point, i.e. cluster_create_security_group = true, it creates an SG that only allows the worker nodes SG. Which was fine with public access, but now with private access, people will require access internally and so a security group on the cluster must allow IP ranges.
To do this I was looking to set cluster_create_security_group to false and then it tried to recreate the cluster. It seems however that you can just add a new security group rule to the current SG using the output from the module cluster_security_group_id as the security_group_id for the rule
Yeah but i think it would be better to just fix this module so it accepts security id's/cidr's and add option to "add_additional_rules", this could be list of cidr's or security group id's. I've already tested this and it's a pretty simple change which would mean users could implement without downtime/destroying current stack or writing additional code to create the rules separately.
Something along the lines of the following addition would be great:
resource "aws_security_group_rule" "cluster_https_additional_ingress" {
description = "Allow communication with the EKS cluster API from additional CIDRs."
protocol = "tcp"
security_group_id = module.eks.cluster_security_group_id
cidr_blocks = var.cluster_endpoint_additional_access_cidr
from_port = 443
to_port = 443
type = "ingress"
}
This would also be an implicit dependency of the null_resource.wait_for_cluster as the additional rules would have to be added to the security group before terraform curls the endpoint.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had recent activity since being marked as stale.
Most helpful comment
Yeah but i think it would be better to just fix this module so it accepts security id's/cidr's and add option to "add_additional_rules", this could be list of cidr's or security group id's. I've already tested this and it's a pretty simple change which would mean users could implement without downtime/destroying current stack or writing additional code to create the rules separately.