-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Create cluster_private_access
security group rules when it should
#981
Conversation
as a FYI, I tried it out in my environment and it worked fine! |
Great. Can you please address this #942 in your PR also ? We should able to create EKS cluster with private and public access. |
Nice, it does seem to fix it. I may be able to try it tomorrow. I'll let you know. |
It does seem to create it in the plan. I can't apply it to test it right know, but when it's merged to master I'll do it eventually and let you know if there's a problem. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Let's wait for @dpiddockcmp feedback.
cluster_private_access
Security Group when it should (only when cluster_create_security_group
and cluster_endpoint_private_access
are both true
)
cluster_private_access
Security Group when it should (only when cluster_create_security_group
and cluster_endpoint_private_access
are both true
)cluster_private_access
Security Group when it should
I hate this damn rule 😆 It keeps generating issues. Plus it breaks the principle of least access by default. We sometimes create a rule that allows access from all IPs that have internal access to the VPC. I don't see how this relates to Personally I would prefer a unique flag that explicitly enables this rule with a note that |
Agree ^^. The actual behavior is totally messed up and doesn't have any sense.
I my mind, the
Agree. I think it's time to rework the security group creation. This was partially discussed in #799 and #792.
Taking the decision on different flag sounds good to me. But instead of adding new variable, we can:
variable "cluster_endpoint_private_access_cidrs" {
description = "List of CIDR blocks which can access the Amazon EKS private API server endpoint, when public access is disabled"
type = list(string)
default = null
}
resource "aws_security_group_rule" "cluster_private_access" {
count = var.create_eks && var.cluster_endpoint_private_access_cidrs != null && var.cluster_endpoint_private_access ? 1 : 0
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = var.cluster_endpoint_private_access_cidrs
security_group_id = aws_eks_cluster.this[0].vpc_config[0].cluster_security_group_id
} This will force everyone who want to have a private access to set explicitly their allowed subnets. |
OK, yes that's a better solution rather than another flag. Although it does raise the risk of the good old ""count" value depends on resource attributes that cannot be determined until apply" error. |
@anthonydahanne if the proposed fix works for you, can you please update your PR accordingly. Thanks again for your time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the same issue and this fix looks good to me
hello there! |
I think it's better to add another switch ( variable "cluster_create_endpoint_private_access_sg_rule" {
description = "Whether to create security group rules for the access to the Amazon EKS private API server endpoint."
type = bool
default = false
}
variable "cluster_endpoint_private_access_cidrs" {
description = "List of CIDR blocks which can access the Amazon EKS private API server endpoint."
type = list(string)
default = null
}
resource "aws_security_group_rule" "cluster_private_access" {
count = var.create_eks && var.cluster_create_endpoint_private_access_sg_rule && var.cluster_endpoint_private_access ? 1 : 0
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = var.cluster_endpoint_private_access_cidrs
security_group_id = aws_eks_cluster.this[0].vpc_config[0].cluster_security_group_id
} |
@barryib - to me, either way is OK. |
66a661a
to
98fd437
Compare
@barryib @dpiddockcmp @otodorov - ready for review! well docs failed because I introduced changes? what's the issue with this check ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
Checks are failing because you don't rebuild docs. Please follow https://github.com/terraform-aws-modules/terraform-aws-eks/#doc-generation to update docs with your new variables.
Actually, every time when someone wants to upgrade something (no matter what) it is mandatory to check for breaking changes in the new version. Also, this will be mention in the Changelog. |
…cess_sg_rule condition Fix terraform-aws-modules#942: Let public access clusters have private SG Changing default cluster_endpoint_private_access_cidrs to null Signed-off-by: Anthony Dahanne <[email protected]>
98fd437
to
f023664
Compare
now it should be good! happy reviewing / merging ! @otodorov @barryib @dpiddockcmp |
cluster_private_access
Security Group when it shouldcluster_private_access
security group rules when it should
@barryib Allô! the PR seems to indicate there are changes requested from you, do you want me to update anything? Thanks |
Just merged. Thank you @anthonydahanne for your contribution. |
…uld (terraform-aws-modules#981) BREAKING CHANGES: Default for `cluster_endpoint_private_access_cidrs` is now `null` instead of `["0.0.0.0/0"]`. It makes the variable required when `cluster_create_endpoint_private_access_sg_rule` is set to `true`. This will force everyone who want to have a private access to set explicitly their allowed subnets for the sake of the principle of least access by default.
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
PR o'clock
Description
Add
cluster_create_security_group
condition to create the security group rule namedcluster_private_access
Resolves #980
Resolves #942
Checklist