-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Specify LaunchTemplate instance tags rather than ASG instance tags #1603
Comments
I'd actually like to see the tags applied to both the launch template and the autoscaling group. Would that work for you, @atheiman ? For us, the reason is that we'd like our IAM policies to only permit a deployer to delete resources belonging to their cluster instances. The only way to achieve this with Launch Templates, because of the unpredictable ARNs which don't include the cluster name, is through tagging the Launch Templates with the cluster that they belong to. |
Yea i think if they were declared in both the asg and launch template that would solve our problem. But if the tags are defined in the launch template I think they propagate onto the asg and ec2 instances . Would have to verify this in AWS. |
I'm trying to enforce a similar 'deny' tagging policy in my organization's accounts. What I've found is the ASG launches the EC2 per the launch template then tags it with the ASG 'tag new instances' config. This causes the 'deny' policy to kick it because the tagging is not part of the first ec2:RunInstances request. When the launch template specifies 'tag instance', this will allow the tags to be part of the initial ec2:RunInstance request. For this issue, that's all that's needed; You can even turn off the ASG based tagging and let the launch template specifications take over and the tag enforcement policy would work. I've validated this on deployments using a role that has a similar 'deny' policy attached. I create a launch template that specifies 'tag instances' yes for my required tags and an ASG using that launch template with 'tag new instances' set to no. Works fine. |
It's probably worth keeping this in-step with the Managed Nodegroup behaviour, when it gets one in aws/containers-roadmap#608. It looks like people in both tickets lean towards tagging the LT with propagation, except for tags that only the ASG needs to have, like the Cluster Autoscaler labels and taints. Then tags on the ASG don't need to propagate. This would also be usefully consistent with #1481 which wants to only list the labels and taints in the config, and have them copied automatically as Tags for Cluster Autoscaler, perhaps enabled by a |
Updating from aws/containers-roadmap#608 again, the decision for Managed Node Groups has been to manage EC2 instance tags via Launch Templates rather than the ASG. ASG tags necessary for scale-from-zero (aws/containers-roadmap#724) are proposed to be handled automatically in a way probably similar to that proposed in #1481. |
Did the tags used to work? I thought they did but all my nodeGroups now no longer have the tags specified in the eksctl configuration. Need to get these tags back in as they are used for Cost reporting. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
Why do you want this feature?
Our AWS Organization uses a Service Control Policy to ensure EC2 instance tags are set on the
ec2:RunInstances
api call. Example SCP requiring the Name tag to be set:eksctl currently creates node group launch templates with no tags defined. When my node group CloudFormation stack attempts to create an autoscaling group from the launch template, I get this error:
API: autoscaling:CreateAutoScalingGroup You are not authorized to use launch template: eksctl-test-nodegroup-ng-1
.What feature/behavior/change do you want?
I would like node group tags to be specified in the LaunchTemplate resource rather than in the AutoScalingGroup resource in the CloudFormation stack.
The text was updated successfully, but these errors were encountered: