Skip to content
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.

Sign up for GitHub

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

Jump to bottom

The provider adds a 0.0.0.0/0 SG rule to Control Plane LB in unmanaged mode. #5196

Open
sl1pm4t opened this issue Nov 1, 2024 · 1 comment · May be fixed by #5198
Open

The provider adds a 0.0.0.0/0 SG rule to Control Plane LB in unmanaged mode. #5196

sl1pm4t opened this issue Nov 1, 2024 · 1 comment · May be fixed by #5198
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@sl1pm4t
Copy link

sl1pm4t commented Nov 1, 2024

/kind bug

What steps did you take and what happened:

  • Create a cluster in an unmanaged VPC mode (i.e. the VPC is created by some other tool).
  • Review the Control Plane load balancer security group rules and see the provider has added a rule allowing all IPv4 addresses (0.0.0.0/0).

What did you expect to happen:

  • I would expect the LB security group rules to only include the external IPs of the pre-existing NAT GW, and any specified in the AWSCluster spec.controlPlaneLoadBalancer.ingressRules field.

Anything else you would like to add:

In my test, the provider was configured to create a public NLB for the apiserver, and I had specified additional allowed sources addresses via the AWSCluster spec.controlPlaneLoadBalancer.ingressRules field

I did some digging through the code, and CAPA adds the 0.0.0.0/0 rule if there are no NAT GW IPs available:
https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/pkg/cloud/services/securitygroup/securitygroups.go#L951-L952

The NAT GW IPs are set on the AWSCluster status in reconcileNatGateways() but, this short circuits in unmanaged mode, and doesn't attempt to detect the IPs associated with the pre-existing NAT Gateways:
https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/pkg/cloud/services/network/natgateways.go#L41-L44

Environment:

  • Cluster-api-provider-aws version: v2.6.1
  • Kubernetes version: (use kubectl version): v1.29.8
  • OS (e.g. from /etc/os-release):
@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 1, 2024
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If CAPA/CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@sl1pm4t sl1pm4t linked a pull request Nov 1, 2024 that will close this issue
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Milestone
No milestone
2 participants
@sl1pm4t @k8s-ci-robot