[bootstrap] control-plane role is missing elasticloadbalancing:DeregisterTargets permission

[dilyevsky]

/kind bug

What steps did you take and what happened:
[A clear and concise description of what the bug is.]
Creating service type=LoadBalancer with service.beta.kubernetes.io/aws-load-balancer-type: nlb annotation for NLB in a capa-managed cluster. Cloud controller complains in the service events:

Warning  UpdateLoadBalancerFailed  19m                   service-controller  Error updating load balancer with new hosts map[ip-10-68-11-224.ec2.internal:{}]: error trying to deregister targets in target group: "AccessDenied: User: arn:aws:sts::XXXX:assumed-role/control-plane.cluster-api-provider-aws.sigs.k8s.io/i-0649faaaedfa64a63 is not authorized to perform: elasticloadbalancing:DeregisterTargets on resource: arn:aws:elasticloadbalancing:us-east-1:XXXX:targetgroup/k8s-awsuseas-XXX-50c5d4e851/XXX because no identity-based policy allows the elasticloadbalancing:DeregisterTargets action\n\tstatus code: 403, request id: a38ddc94-4f99-444e-88f2-825d445ffc5f"

What did you expect to happen:
control-plane role should have elasticloadbalancing:DeregisterTargets permissions. It appears only RegisterTargets is present in the bootstrap config

cluster-api-provider-aws/cmd/clusterawsadm/cloudformation/bootstrap/cloud_provider_integration_control_plane.go

Line 92 in 50af6ec

"elasticloadbalancing:RegisterTargets",

while AWS Cloud Provider want Deregister too https://github.com/kubernetes/cloud-provider-aws/blob/5f394ba297bf280ceb3edfc38922630b4bd83f46/docs/prerequisites.md?plain=1#L66.

Anything else you would like to add:
I can send a fix.

Environment:

• Cluster-api-provider-aws version: v1.3.0
• Kubernetes version: (use kubectl version): v1.23.4
• OS (e.g. from /etc/os-release): n/a

[sedefsavas]

/triage accepted

This looks valid to me. We are missing ExtraStatements for control plane role so there is no workaround.

We might need to add it to ManagedControlPlane role too.

[dilyevsky]

K thanks I'll send a PR

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale