forked from aws/aws-cdk
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(eks): circular dependencies when security groups from other stack…
…s are used (aws#10339) @eladb While working on this for the `aws-eks-next` module, i've started to second guess whether we really need to force cluster replacement. This little PR fixes all the circular dependency issues as well as corrects the `cluster.connections` to include the EKS managed cluster security group. **It does not require cluster replacement**. Merging this PR will leave two quirks/limitations: - The cluster will have a redundant control plane security group, just like it has now. While redundant, it doesn't hurt, and doesn't really justify a cluster replacement. - One cluster per stack, just like we have now. I think we've already agreed that this limitation also does not justify cluster replacement, and the only reason we wanted to implement it is because we wanted to piggy back on the previous argument, which I now believe is not strong enough. WDYT? -------- This PR resolves a few problem related to circular dependencies when the cluster is configured with security groups from other stacks. ## Problem Currently, the cluster creates a dedicated security group for the `KubectlProvider` and configures the main control plane security group to allow connections from it: https://github.com/aws/aws-cdk/blob/f5c5d060ffee19ac3daa47cbf6df8d3563133433/packages/%40aws-cdk/aws-eks/lib/cluster.ts#L918-L924 This eventually creates ingress rules in the stack of control plane security group. These ingress rules refer to the `KubectlProvider` creates in the cluster stack, hence, a dependency if formed between the control plane security group stack, and the cluster stack. `Control Plane Security Group Stack => Cluster Stack` (Control plane sg needs to allow connections from kubectl sg) On the other hand, the cluster stack naturally depends on the control plane security group stack because the cluster needs the security group when its created. And so: `Cluster Stack => Control Plane Security Group Stack` (Cluster needs the security group) When these two stacks are different, a circular dependency is created. ## Solution Do not create a security group for the `KubectlProvider` at all, and simply re-use the EKS managed security group. This security group is already configured to allow connections to the control plane, so if we simply attach it to the `KubectlProvider`, everything should work. This avoids the creation of the first dependency direction. Fixes aws#9754 Fixes aws#10020 Fixes aws#9536 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
- Loading branch information
Showing
4 changed files
with
1,040 additions
and
590 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.