Ambiguity when checking for existence of Backend SGs

[visit1985]

When searching for the existence of backend SGs, the controller searches by tags and does not consider the case where multiple SGs with that tags are returned.

To avoid ambiguity, the below function should either search by SG name (which is already present as an input parameter), or return an error when multiple SGs with the given tags are found.

https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/8ba34e27224d1f7a56f0e416086c43b6877c7e65/pkg/networking/backend_sg_provider.go#L284-L310

[shraddhabang]

Hey @visit1985 , While configuring the backend sg, the LBC uses a shared backend SG for all the resources which it creates once and applies these tags. So the customer should avoid to use the same tag for other sgs. If you want to configure your own backend sg, you can disable this automanagement by setting flag --enable-backend-security-group=false. Then in that case the LBC will configure the SG that you provide.

More info on SG management : https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/security_groups/#backend-security-groups

[visit1985]

Yes, right. But even the it’s better to fail instead if using a random SG via sgs[0].

[M00nF1sh]

@visit1985 We should avoid dependencies on the name(which allows us to change naming patterns) I'm curious why you would run into this issue? since the backendSG is already scoped by the clusterTag & resourceTag and vpcID, there shouldn't be more than one such backendSG exists. Did you created a SG with same set of tags out of the controller?

[visit1985]

Yes, someone created it during preparation to migrate to command line flag --backend-security-group. For some deployments this resulted in a scenario where both SGs are in use.

Adding an error for len(sgs) > 1 should be backwards compatible, does not create a dependency on name and would inform the customer that he should avoid to use the same tag for other SGs.

[k8s-triage-robot]

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

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

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

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

/lifecycle stale

[visit1985]

/remove-lifecycle stale

[k8s-triage-robot]

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

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

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue 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.

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

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

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

/lifecycle rotten

[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-sigs/prow repository.