containers-roadmap
containers-roadmap copied to clipboard
[EKS] [request]: AUTO MODE - Explicitly set spec.associatePublicIPAddress flag explicitly in AWS EKS AutoMode
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request Explicitly set spec.associatePublicIPAddress flag explicitly in AWS EKS AutoMode
Which service(s) is this request for? This could be Fargate, ECS, EKS, ECR
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? We are currently facing an issue while using AWS EKS Auto mode in a private subnet. The node pools are failing and remain in a "Not Ready" state. This appears to be caused by below SCP policy we have in place, which is designed to prevent the creation of EC2 instances with public IP addresses. SCP Policy: { "Sid": "sid123", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:::network-interface/*", "Condition": { "BoolIfExists": { "ec2:AssociatePublicIpAddress": "true" } } }
Our observation is that EKS Auto mode attempts to launch instances in private subnets, but the operation is being blocked by the SCP. Specifically, any RunInstances API call that does not explicitly set the associatePublicIPAddress flag is being denied.
Request: We are looking for a solution or a supported method in EKS AutoMode —such as an option in NodeClass—to pass or configure spec.associatePublicIPAddress explicitly. This would provide users the flexibility to control this setting and ensure that it is properly propagated to the underlying RunInstances API call, avoiding unintended denials by SCP.
We would appreciate any guidance or support to help address this issue.
Are you currently working around this issue?
Additional context
Attachments
Can you ensure that the subnets selected by your nodeclass don't have MapPublicIpOnLaunch set?
If you have a NodeClass named default, this should work:
kubectl get nodeclass default -o json | jq -r '.status.subnets[].id' | xargs aws ec2 describe-subnets --subnet-id | jq '.Subnets[] | "\(.SubnetId) \(.MapPublicIpOnLaunch)"'
Yes, we are deploying in private subnet(s), and below is the output we got -
subnet-xxxxx False subnet-xxxxx False
This has been addressed, docs are in being process of being updated
https://github.com/awsdocs/amazon-eks-user-guide/pull/1085