amazon: Impossible to associate public IP in default subnet w/o auto-assign public IP

[ghost]

This issue was originally opened by @emcpow2 as hashicorp/packer#6589. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Packer v1.2.5

Builder type amazon-ebs

Assuming default networking setup.

Steps to reproduce:

1. Find default VPC and disable Auto-assign public IPv4 address in its default subnets
2. Leave vpc_id and subnet_id in default values(unset)
3. Set associate_public_ip to true
4. Start packer build
5. EC2 instance will be created without public IP address

More information
associate_public_ip_address : true does not work here, because based on source code it only takes effect if subnet_id(or vpc_id) is specified.
https://github.com/hashicorp/packer/blob/v1.2.5/builder/amazon/common/step_run_source_instance.go#L157-L167

	if s.SubnetId != "" && s.AssociatePublicIpAddress {
		runOpts.NetworkInterfaces = []*ec2.InstanceNetworkInterfaceSpecification{
			{
				DeviceIndex:              aws.Int64(0),
				AssociatePublicIpAddress: &s.AssociatePublicIpAddress,
				SubnetId:                 &s.SubnetId,
				Groups:                   securityGroupIds,
				DeleteOnTermination:      aws.Bool(true),
			},
		}
	} else {

associate_public_ip_address must work for default VPC in spite of disabled Auto-assign public IPv4 address.

[v3rm0n]

Having the same issue since "AWS Foundational Security Best Practices v1.0.0" recommends removing auto assigning public IP addresses in public subnets.

Removing the s.SubnetId != "" check works and the build is successful even if there is no subnet id specified. Can this check just be removed since it is not actually needed?

[johnbindel]

For me, this resolved it:

associate_public_ip_address = true,
subnet_id = "PUBLIC_SUBNET_ID_HERE"

Then it was launched in a public subnet (which is necessary to allow public IPs) and with a public IP (which for my environment was disabled by default for security). Problem solved.

[v3rm0n]

That works, but then you have to know the subnet id beforehand, it should work without it as well.

[johnbindel]

@v3rm0n How would it know what subnet to put it in? It would need to be a public subnet in order to be assigned a public IP. What would you prefer, that it would find a random public subnet to put it in?

[v3rm0n]

Yeah, random subnet from default VPC is fine for my use case.

[ozbillwang]

My use case is, I need set subnetId, AssociatePublicIpAddress to false and set AssociatePublicIpAddress in NetworkInterfaces when run_instance

But seems if I set AssociatePublicIpAddress to false, it never goes in the if condition and always to else

if s.SubnetId != "" && s.AssociatePublicIpAddress {

https://github.com/hashicorp/packer-plugin-amazon/blob/v1.0.4/builder/common/step_run_source_instance.go#L188-L201

	if subnetId != "" && s.AssociatePublicIpAddress {
		runOpts.NetworkInterfaces = []*ec2.InstanceNetworkInterfaceSpecification{
			{
				DeviceIndex:              aws.Int64(0),
				AssociatePublicIpAddress: &s.AssociatePublicIpAddress,
				SubnetId:                 aws.String(subnetId),
				Groups:                   securityGroupIds,
				DeleteOnTermination:      aws.Bool(true),
			},
		}
	} else {
		runOpts.SubnetId = aws.String(subnetId)
		runOpts.SecurityGroupIds = securityGroupIds
	}

[ozbillwang]

If use default vpc, that means, no nat gateway, AssociatePublicIpAddress has to be true. otherwise, no internet access and can't update or install anything.

But if paker build in own vpc, we need AssociatePublicIpAddress to be false, if not allow public IP. So we set subnetId and AssociatePublicIpAddress to false

My understand is, it should always go in if condition, never need else when subnetId is set

So this line

if subnetId != "" && s.AssociatePublicIpAddress {

Need be changed to

if subnetId != "" && {

I am not golang developer, not sure how to change a plugin, and build with packer core. Any hints?

[neechbear]

Is there any timeline for addressing this bug?

As it stands this means that Packer is incompatible with AWS Foundational Security Best Practices controls as documented at https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-ec2-15 / https://docs.aws.amazon.com/config/latest/developerguide/subnet-auto-assign-public-ip-disabled.html which states "[EC2.15] EC2 subnets should not automatically assign public IP addresses".

[neechbear]

For me, this resolved it:

associate_public_ip_address = true,
subnet_id = "PUBLIC_SUBNET_ID_HERE"

Then it was launched in a public subnet (which is necessary to allow public IPs) and with a public IP (which for my environment was disabled by default for security). Problem solved.

To expand upon this, if you want to lookup a random subnet on your default you can do the following:

  vpc_filter {
    filters = {
      "isDefault": "true"
    }
  }

  # https://github.com/hashicorp/packer-plugin-amazon/issues/18
  # https://github.com/hashicorp/packer/issues/6589
  # https://github.com/hashicorp/packer-plugin-amazon/blob/main/builder/common/step_run_source_instance.go#L186
  # https://github.com/hashicorp/packer-plugin-amazon/blob/main/builder/common/step_network_info.go#L86
  # https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html

  associate_public_ip_address = true

  subnet_filter {
    most_free = true
    random    = true
    filters = {
      "subnet-id": "*"
    }
  }

[bbratchiv]

this is still reproducible on v1.1.5 amazon plugin. Workaround from neechbear still applies however

[github-actions]

This issue has been synced to JIRA for planning.

JIRA ID: HPR-1056

[Glyphack]

Hi all, I can spend some time on this.

Just to be clear on my side, the issue is that unless the subnet id i explicitly set, the instance won't get a public ip address.
So packer needs to check if the available subnets are from the default vpc and Auto-assign public IPv4 address option is enabled then assign public ip, right?

[lbajolet-hashicorp]

Hey everyone,

I'm working on this feature now, from what I gather, and to @Glyphack's point, it looks like the main problem here is that the associate_public_ip_address option is completely ignored if a subnet_id is not specified, so that's what is to change here so that if the associate_public_ip_address option is set to either true or false, it should apply to the configuration of the instance we're creating.

I'll rework the logic that manages that, and try to come up with acceptance tests so we can check that it works as expected. I'll keep this issue up-to-date on that, and hopefully come up with a PR to fix this in the coming days.