AWS node/instance security group - misuse of cluster tag

[Benjamin-Dobell]

Cross post of k8s issue. Aside: Is there an official policy on where cloud provider issues should be opened?

---

The AWS cloud provider cluster tag, which defines ownership semantics, is presently being utilised improperly for unrelated purposes. In particular, attempting to identify which instance security groups should be updated to allow inbound load balancer traffic.

This means we (or our controllers) are unable to attach additional security groups to our instances (without "leaking" security group resources).

Please refer to the upstream issue for further details kubernetes/kubernetes#73906

[Pratima]

Completely agree. Would like to bump this post. We can't use istio nlb ingress with our worker pools that have multiple security groups.
We use Terraform AWS EKS module to setup our cluster.

[Benjamin-Dobell]

Looks like the cluster-api-provider-aws has new tags:

Labels for Cluster API managed infrastructure and cloud-provider managed infrastructure overlapped. The breaking change introduces a new label for Cluster API to use as well as a tool to convert labels on existing clusters to the new format.

I'm still using Kops, but keen to migrate.

However, it looks like the cloud-provider still documents the owned cluster tag as being tied to the lifecycle of the cluster:

	// ResourceLifecycleOwned is the value we use when tagging resources to indicate
	// that the resource is considered owned and managed by the cluster,
	// and in particular that the lifecycle is tied to the lifecycle of the cluster.
        ResourceLifecycleOwned = "owned"

Perhaps the intention is that this tag now signifies ownership by the cloud-provider (rather than the cluster)?

Would appreciate it if a maintainer could chime in clarifying the situation.

[manvendra-singh0x7cd]

@Benjamin-Dobell Any updates on this ?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.