🐛 additionalControlPlaneIngressRules are ignored for AWSManagedControlPlane

[CharlieR-o-o-t]

It looks like additionalControlPlaneIngressRules do not work for AWSManagedControlPlane.
When this field is specified, the additional Security Group is created, but the ingress rules are not actually provisioned.

Steps to reproduce:

1. Define additionalControlPlaneIngressRules in AWSManagedControlPlane with sourceSecurityGroupRules:

                  protocol: tcp
                  fromPort: 10250
                  toPort: 10250
                  sourceSecurityGroupRoles:
                    - node-eks-additional

2. Observe the results.

Security group created, but didn't provisioned.
From what I can see, processIngressRulesSGs() is not called for managed control plane flows:

cluster-api-provider-aws/pkg/cloud/services/securitygroup/securitygroups.go

Line 694 in da8e793

case infrav1.SecurityGroupEKSNodeAdditional:

As a result, even though the SG exists, it remains empty.

Additionally, I noticed that a dedicated role (node-eks-additional) is introduced and is bound directly to AdditionalControlPlaneIngressRules:

cluster-api-provider-aws/pkg/cloud/scope/managedcontrolplane.go

Line 478 in da8e793

// AdditionalControlPlaneIngressRules returns the additional ingress rules for the control plane security group.

This seems confusing from a user perspective.

What I would expect as a user:

additionalControlPlaneIngressRules should allow configuring security group rules applied to the managed control plane entrypoint (as far as this is technically feasible for EKS).

AWSManagedControlPlane should include the default node SG role, and some alternative for controlplane sg role (similar to self-managed clusters):

cluster-api-provider-aws/controlplane/eks/controllers/awsmanagedcontrolplane_controller.go

Line 71 in da8e793

var defaultEKSSecurityGroupRoles = []infrav1.SecurityGroupRole{

This would make it possible to expose NodePorts (and similar traffic) on worker nodes, while additionalNodeIngressRules would control extensions on the node SG instead of being tied to a separate node-eks-additional SG.

for now additionalNodeIngressRules is always ignored, even if provided with AWSManagedControlPlaneSpec (because sg role node not handled by default.

Please let me know if I misunderstood the intended behavior, or if there is a recommended alternative approach for configuring SG rules in managed control plane scenarios.

I can prepare PR, but first want to discuss that.

/kind bug

[k8s-ci-robot]

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.

Details

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.