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

[ediskandarov]

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.

[rickard-von-essen]

I'm not sure I follow? Do you think this is a bug? To me what you describe is the intended behaviour.

[ediskandarov]

intended behaviour is if I set associate_public_ip_address, instance has associated public ip address

[rickard-von-essen]

Ok, I got it. I'll edit the original post to make it clearer.

[grealish]

This issue will bite allot of people, can we have some verbosity in packer that makes it obvious to set associate_public_ip_address
once thats then done one could close this issue

[xjables]

I think this issue is subtly deceptive. In reality, this value is not strictly a boolean. It has three distinct cases:

1. true: Assigned a public IP address to the instance.
2. false: Do not assigned a public IP address to the instance.
3. unset: Defer to the auto-assign IPv4 value for the subnet.

These correspond to what we see when launching an instance in the console:

1. Enable
2. Disable
3. Use subnet settings (defer to auto-assign)

However, calling the parameter "associate_public_ip_address" and making it with a boolean, we are forced to select only two of the three possible outcomes. The way packer is currently programmed (mentioned above by @toidi), item 2 has been dropped and the cases are modified slightly.

1. If the subnetID is set and AssociatePublicIpAddress is true, then assign a public IP to the instance.
2. Else, defer to the subnet auto-assign configuration.

The fact of "subnetID being set" seems to be proxy for "we are in a non-default VPC", as the subnetID must be set for default VPCs (per the packer documentation). This has the added effect of not being able turn off public IP assignment if you're in a default VPC (which is how I came across this problem) as well as not being able to turn it on in your default VPC if the default subnet has been modified to not to assign public IPs (OP's problem)

However, neither of the control pathways listed coincide with what AWS says that the parameter means, namely:

[AssociatePublicIpAddress] indicates whether to assign a public IPv4 address to an instance you launch in a VPC. [...] If launching into a default subnet, the default value is true.

The last sentence informs us indirectly that the subnet will choose this for us if AssociatePublicIpAddress is not invoked on the network interface. I have modified packer (version 1.6.2) to test this to be sure and have found that, yes, ignoring AssociatePublicIpAddress altogether causes the subnet to decide whether or not the instance receives an IP address.

There are two solutions I see:

1. If we want to keep the parameter associate_public_ip_address, I think it would be a good idea to bring it in congruence with how the AssociatePublicIpAddress golang boolean parameter actually works in AWS. This would mean "true" and "false" coincide with "enable" and "disable" and letting the subnet decide whether or not to assign a public IP is off the table completely. This is the behavior I initially inferred when I read the packer documentation and read further into the AWS docs.

Probably a more sensible default would 'true' in this case.

Or,

2. associate_public_ip_address needs to be deprecated and replaced by something like public_ip_assignment_policy whose values could be something like enable, disable, and subnet to keep with the console launch options. Then logically in the background, enable and disable could invoke the AssociatePublicIpAddress boolean parameter in the InstanceNetworkInterfaceSpecification struct so it would be honored, and the subnet option could follow the "else" case from above and ignore AssociatePublicIpAddress so that the public IP decision will defer to the subnet auto-assign configuration.

[SwampDragons]

I think I like option 2 -- it's more explicit and more flexible. I'm not sure when I can have someone work on it but PRs are welcome and I don't think this would be too complex an issue for a new community member to tackle.

We'd want to honor the associate_public_ip_address for a couple of releases rather than truly deprecating it all at once, for backwards compatibility.

[ghost]

This issue has been automatically migrated to hashicorp/packer-plugin-amazon#18 because it looks like an issue with that plugin. If you believe this is not an issue with the plugin, please reply to hashicorp/packer-plugin-amazon#18.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.