Explicitly define AssociatePublicIpAddress in Launch Templates

[lorrrrrrrenzo]

Tell us about your request

Explicitly set AssociatePublicIpAddress in launch templates. The missing key in launch templates results in the rejection of EC2 instance creation requests in environments where AssociatePublicIpAddress is required to be false by the use of a BoolIfExists condition, an AWS-recommended best practice, an instance of which can be found here under the subheading "Recommended Combination". To be explicit, this problem is occurring with a subnet which is not configured to assign public IP addresses.

I am aware that the project would prefer to have subnet settings determine whether an attempt to associate a public IP address is actually made. Ensuring that a value exists, either true or false, does not change this design decision.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

See above.

Are you currently working around this issue?

I am using custom launch templates, which introduces a great deal of overhead for a basic and philosophically-aligned feature.

Additional Context

Example policy statement, demonstrating the cause of the conflict:

{
    "Effect": "Deny",
    "Action": [
        "ec2:RunInstances"
    ],
    "Condition": {
        "BoolIfExists": {
            "ec2:AssociatePublicIpAddress": "true"
        }
    },
    "Resource": "arn:aws:ec2:*:*:network-interface/*"
}

Sketch of a possible solution:
main...lorenzadia:karpenter:lorenzo.explictly-disable-public-ipaddr-in-launch-template

Attachments

No response

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

[bwagner5]

Thanks for creating this issue and opening a PR! I think the long term solution for the API is to support the NetworkInterfaces block within the AWSNodeTemplate, but I think we could move forward with a patch for your issue where we explicitly set the AssociatePublicIpAddress when the subnets are set to not associate a public IP address by default.

[jonathan-innis]

@lorrrrrrrenzo We're re-evaluating this behavior of Karpenter, only because we now surface the associatePublicIPAddress field through the EC2NodeClass so you should be able to explicitly set this now. Do you think you could update your EC2NodeClasses to have this field explicitly set if you have policies that require it?