Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EKS created Cluster Security Group doesn't have tags mentioned in additionalTags of AWSManagedControlPlane #5223

Open
vishu2498 opened this issue Nov 21, 2024 · 1 comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@vishu2498
Copy link
Contributor

/kind bug

What steps did you take and what happened:

The spec section of AWSManagedControlPlane allows us to provide additionalTags. These tags are then propagated to all the resources created by CAPA for EKS clusters like Cluster, Subnet, Security Group (node-eks-additional) etc. but it only pushes the tag to the additional security group for the cluster and not the primary security group used by the cluster.

From this documentation:
https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html
It is pretty evident that EKS creates a Cluster Security Group by itself and provides its own tags on it. (CAPA neither creates it and nor handles that security group)

Also, reading the CAPA code here:
https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/pkg/cloud/services/eks/securitygroup.go

CAPA does indeed know that these security group roles (node & cluster) are created by EKS and updates the values in the status section of AWSManagedControlPlane.
Even though the tags are propagated to the node-eks-additional security group which is created by CAPA itself, these tags are not propagated to Cluster Security Group.

What did you expect to happen:

All of the tags mentioned in additionalTags section of AWSManagedControlPlane should be propagated to all the resources of EKS cluster including its default Cluster Security Group which is created by EKS only and not CAPA. CAPA has the code to fetch information from that security group. It should also apply the tags on default Cluster Security Group.

This way even if a script is used which filters out resources of an EKS cluster using tags, it should also receive the default Cluster Security Group created by EKS.

Anything else you would like to add:
Many people have faced similar issue where they want this specific security group to also get tagged so that filtering out resources gives correct information: hashicorp/terraform-provider-aws#29919

Environment:

  • Cluster-api-provider-aws version: v1.5.2 & Latest
  • Kubernetes version: (use kubectl version): All kubernetes versions
  • OS (e.g. from /etc/os-release): Linux
@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-priority labels Nov 21, 2024
@k8s-ci-robot
Copy link
Contributor

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.

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.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants