Unmanaged SecurityGroups should also get tagged for CCM

[dkoshkin]

/kind feature

Describe the solution you'd like
When using an unmanaged SecurityGroup for [spec.network.securityGroupOverrides.lb](http://spec.network.securitygroupoverrides.lb/) CAPA should tag it with kubernetes.io/cluster/<cluster-name> so that CCM can create ELBs for LoadBalancer Services without requiring users to tag the SecurityGroup themselves.

Anything else you would like to add:
When an instance has multiple SecurityGroups attached, CCM requires 1 of them to be tagged https://github.com/kubernetes/cloud-provider-aws/blob/8d2f0fd2b1b574bde3239a344bd0a9a4f244cdb0/pkg/providers/v1/aws.go#L4479-L4485

Currently managed SecurityGroups are already tagged with the required kubernetes.io/cluster tag. Unmanaged Subnets are also already tagged. It would not be a stretch for CAPA to also tag the SecurityGroup.

Originally discussed in Slack.

Environment:

• Cluster-api-provider-aws version:
  v1.4.1
• Kubernetes version: (use kubectl version):
  v1.22.8
• OS (e.g. from /etc/os-release):

[Ankitasw]

As per the slack thread, we would be doing this in Next milestone, is it correct @sedefsavas ?

[sedefsavas]

Yes, added this under v1beta2 changes.

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[richardcase]

/milestone v2.0.0

[dlipovetsky]

I'll pair on this with @dkoshkin.

/assign

[dlipovetsky]

/triage accepted
/priority important-soon

[dlipovetsky]

@dkoshkin and I looked over this today. Here's the plan, roughly:

1. As part of the unmanaged infrastructure test, start exercising ELB creation (this is not done today).
2. As part of the unmanaged infrastructure test, provide an security group override for the loadbalancer subnet (by setting the spec.network.securityGroupOverrides["lb"] field on the AWSCluster resource).
   • We expect the test to fail at this point, because the CCM will return an error, because it can't choose from among the multiple security groups, since none of them has the required tags.
3. Tag user-provided security groups in https://github.com/kubernetes-sigs/cluster-api-provider-aws//blob/5f5e184dd31d94573a73f7f34271bfb5a1084ec0/pkg/cloud/services/securitygroup/securitygroups.go#L122-L134.
   • We expect the test to pass after this is implemented.

[dlipovetsky]

Important: As we agreed to in #3854. CAPA should apply the CCM tag on cluster create, and remove it on cluster delete.

[richardcase]

/milestone v2.1.0

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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/test-infra repository.