[JIRA] (JENKINS-58578) Public IP can still be assigned when Associate Public IP is disabled, depending on subnet(s)

0 views
Skip to first unread message

andgoldin@gmail.com (JIRA)

unread,
Jul 19, 2019, 11:27:03 PM7/19/19
to jenkinsc...@googlegroups.com
Andrew Goldin created an issue
 
Jenkins / Bug JENKINS-58578
Public IP can still be assigned when Associate Public IP is disabled, depending on subnet(s)
Issue Type: Bug Bug
Assignee: FABRIZIO MANFREDI
Components: ec2-plugin
Created: 2019-07-20 03:26
Environment: Master: Docker jenkins:2.176.2 running in Kubernetes, Workers: CentOS EC2 w/ Docker 18.09.6 and OpenJDK 8, EC2 plugin version: 1.43
Priority: Minor Minor
Reporter: Andrew Goldin

Issue

When configuring agent templates for the EC2 plugin, if you choose subnet(s) that have "Auto-assign public IPv4 address" enabled (on the AWS side), then agents will be launched with a public IPv4 address whether "Associate Public IP" is enabled in Jenkins or not. I am not sure if this is the intended behavior of the plugin, but for me it is not the expected behavior.

Observed/expected behavior

Given a subnet with "Auto-assign public IPv4 address" enabled in AWS but "Associate Public IP" disabled in Jenkins:

  • Observed: Agent launches with public IP
  • Expected: Agent launches without public IP

How to reproduce

In an agent template:

  1. Use a subnet that has "Auto-assign public IPv4 address" enabled in AWS
  2. Ensure "Associate Public IP" is unchecked
  3. Launch an agent using the template
  4. Check EC2 instance in the AWS console or other method
  5. Instance will have a public IPv4 address and public DNS

Workaround

This issue unsurprisingly does not occur when using a subnet that has "Auto-assign public IPv4 address" disabled. We are doing this as a workaround for now. The subnets I eventually wish to use happen to have this flag enabled (for other purposes), but for Jenkins I'd like to be able to use these subnets while not assigning public IPs to agents.

Possible fix

Based on some digging through the code, I believe the possible culprits are here for on-demand instances and here for spot instances, namely:

if (getAssociatePublicIp()) {
    net.setAssociatePublicIpAddress(true);
    net.setDeviceIndex(0);
    riRequest.withNetworkInterfaces(net);
}

Here, if associatePublicIp is true, then true will be passed to the network interface. However, if associatePublicIp is false, then it is likely instead defaulting to whatever is set on the subnet. Given this, I see two possible solutions:

  1. If associatePublicIp is false, then explicitly pass false to the network interface.
  2. Include an additional flag for whether or not to use the subnet's own auto-assign setting. Then if the choice is made to not use it, explicitly pass the value of associatePublicIp.
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

andgoldin@gmail.com (JIRA)

unread,
Jul 19, 2019, 11:35:02 PM7/19/19
to jenkinsc...@googlegroups.com
Andrew Goldin updated an issue
Change By: Andrew Goldin
h2. Issue


When configuring agent templates for the EC2 plugin, if you choose subnet(s) that have "Auto-assign public IPv4 address" enabled (on the AWS side), then agents will be launched with a public IPv4 address whether "Associate Public IP" is enabled in Jenkins or not. I am not sure if this is the intended behavior of the plugin, but for me it is not the expected behavior.
h2. Observed/expected behavior


Given a subnet with "Auto-assign public IPv4 address" enabled in AWS but "Associate Public IP" disabled in Jenkins:
* Observed: Agent launches with public IP
* Expected: Agent launches without public IP

h2. How to reproduce

In an agent template:
# Use a subnet that has "Auto-assign public IPv4 address" enabled in AWS
# Ensure "Associate Public IP" is _unchecked_
# Launch an agent using the template
# Check EC2 instance in the AWS console or other method
# Instance will have a public IPv4 address and public DNS

h2. Workaround


This issue unsurprisingly does not occur when using a subnet that has "Auto-assign public IPv4 address" disabled. We are doing this as a workaround for now. The subnets I eventually wish to use happen to have this flag enabled (for other purposes), but for Jenkins I'd like to be able to use these subnets while not assigning public IPs to agents.

h2. Possible fix

Based on some digging through the code, I believe the possible culprits are [here|https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L673-L677] for on-demand instances and [here|https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L990-L994] for spot instances, namely:
{code:java}

if (getAssociatePublicIp()) {
    net.setAssociatePublicIpAddress(true);
    net.setDeviceIndex(0);
    riRequest.withNetworkInterfaces(net);
}
{code}
Here, if {{associatePublicIp}} is {{true}}, then {{true}} will be passed to the network interface. However, if {{associatePublicIp}} is {{false}}, then it is likely instead defaulting to whatever is set on the subnet. Given this, I see two possible solutions:
# If {{associatePublicIp}} is {{false}}, then explicitly pass {{false}} to the network interface.
# Include an additional flag for whether or not to use the subnet's own auto-assign setting. Then if the choice is made to _not_ use it, explicitly pass the value of {{associatePublicIp}}.

The second option (or something similar) is likely safer as it still allows for the default setting on the subnet to be used if desired.

andgoldin@gmail.com (JIRA)

unread,
Jul 19, 2019, 11:35:02 PM7/19/19
to jenkinsc...@googlegroups.com

andgoldin@gmail.com (JIRA)

unread,
Jul 19, 2019, 11:38:03 PM7/19/19
to jenkinsc...@googlegroups.com
Andrew Goldin updated an issue
h2. Issue

When configuring agent templates for the EC2 plugin, if you choose subnet(s) that have "Auto-assign public IPv4 address" enabled (on the AWS side), then agents will be launched with a public IPv4 address whether "Associate Public IP" is enabled in Jenkins or not. I am not sure if this is the intended behavior of the plugin, but for me it is not the expected behavior.
h2. Observed/expected behavior

Given a subnet with "Auto-assign public IPv4 address" enabled in AWS but "Associate Public IP" disabled in Jenkins:
* Observed: Agent launches with public IP
* Expected: Agent launches without public IP

h2. How to reproduce

In an agent template:
# Use a subnet that has "Auto-assign public IPv4 address" enabled in AWS
# Ensure "Associate Public IP" is _unchecked_
# Launch an agent using the template
# Check EC2 instance in the AWS console or other method
# Instance will have a public IPv4 address and public DNS

h2. Workaround

This issue unsurprisingly does not occur when using a subnet that has "Auto-assign public IPv4 address" disabled. We are doing this as a workaround for now. The subnets I eventually wish to use happen to have this flag enabled (for other purposes), but for Jenkins I'd like to be able to use these subnets while not assigning public IPs to agents.

h2. Possible fix

Based on some digging through the code, I believe the possible culprits are 
* [here|https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L673-L677] * for on-demand instances and * [here|https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L990-L994] * for spot instances, namely:

{code:java}
if (getAssociatePublicIp()) {
    net.setAssociatePublicIpAddress(true);
    net.setDeviceIndex(0);
    riRequest.withNetworkInterfaces(net);
}
{code}
Here, if {{associatePublicIp}} is {{true}}, then {{true}} will be passed to the network interface. However, if {{associatePublicIp}} is {{false}}, then it is likely instead defaulting to whatever is set on the subnet. Given this, I see two possible solutions:
# If {{associatePublicIp}} is {{false}}, then explicitly pass {{false}} to the network interface.
# Include an additional flag for whether or not to use the subnet's own auto-assign setting. Then if the choice is made to _not_ use it, explicitly pass the value of {{associatePublicIp}}.

The second option (or something similar) is likely safer as it still allows for the default setting on the subnet to be used if desired.

andgoldin@gmail.com (JIRA)

unread,
Jul 19, 2019, 11:51:03 PM7/19/19
to jenkinsc...@googlegroups.com
Andrew Goldin updated an issue
h2. Issue

When configuring agent templates for the EC2 plugin, if you choose subnet(s) that have "Auto-assign public IPv4 address" enabled (on the AWS side), then agents will be launched with a public IPv4 address whether "Associate Public IP" is enabled in Jenkins or not. I am not sure if this is the intended behavior of the plugin, but
for me it is not the expected behavior I would like a way to be able to _not_ assign a public IP, even if I've chosen a subnet with this setting enabled .

andgoldin@gmail.com (JIRA)

unread,
Jul 20, 2019, 8:33:02 AM7/20/19
to jenkinsc...@googlegroups.com
Andrew Goldin updated an issue
h2. Issue

When configuring agent templates for the EC2 plugin, if you choose subnet(s) that have "Auto-assign public IPv4 address" enabled (on the AWS side), then agents will be launched with a public IPv4 address whether "Associate Public IP" is enabled in Jenkins or not. I am not sure if this is the intended behavior of the plugin, but I would like a way to be able to _not_ assign a public IP, even if I've chosen a subnet with this setting enabled.

h2. Observed/expected behavior

Given a subnet with "Auto-assign public IPv4 address" enabled in AWS but "Associate Public IP" disabled in Jenkins:
* Observed: Agent launches with public IP
* Expected: Agent launches without public IP

h2. How to reproduce

In an agent template:
# Use a subnet that has "Auto-assign public IPv4 address" enabled in AWS
# Ensure "Associate Public IP" is _unchecked_
# Launch an agent using the template
# Check EC2 instance in the AWS console or other method
# Instance will have a public IPv4 address and public DNS

h2. Workaround

This issue unsurprisingly does not occur when using a subnet that has "Auto-assign public IPv4 address" disabled. We are doing this as a workaround for now. The subnets I eventually wish to use happen to have this flag enabled (for other purposes), but for Jenkins I'd like to be able to use these subnets while not assigning public IPs to agents.
h2. Possible fix

Based on some digging through the code, I believe the possible culprits are *[here|https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L673-L677]* for on-demand instances and *[here|https://github.com/jenkinsci/ec2-plugin/blob/master/src/main/java/hudson/plugins/ec2/SlaveTemplate.java#L990-L994]* for spot instances, namely:
{code:java}
if (getAssociatePublicIp()) {
    net.setAssociatePublicIpAddress(true);
    net.setDeviceIndex(0);
    riRequest.withNetworkInterfaces(net);
}
{code}
Here, if {{associatePublicIp}} is {{true}}, then {{true}} will be passed to the network interface. However, if {{associatePublicIp}} is {{false}}, then it is likely instead defaulting to whatever is set on the subnet. Given this, I see two possible solutions would propose something like the following :
# If {{associatePublicIp}} is {{false}}

For "Associate Public IP"
, then explicitly pass {{false}} utilize a drop-down menu similar to the network interface.
# Include an additional flag for whether or not to use
one in the AWS console itself, which has three options: Use subnet 's own auto-assign setting (default), Yes, and No . Then if the choice When "No" is made to _not_ use it selected , explicitly pass the value of in {{ associatePublicIp false }}.

The second option (or something similar) is likely safer as it still allows
Perhaps use an enum for the default setting on the subnet this, similar to be used if desired ConnectionStrategy .

fabrizio.manfredi@gmail.com (JIRA)

unread,
Aug 10, 2019, 3:38:02 PM8/10/19
to jenkinsc...@googlegroups.com
FABRIZIO MANFREDI started work on Bug JENKINS-58578
 
Change By: FABRIZIO MANFREDI
Status: Open In Progress

fabrizio.manfredi@gmail.com (JIRA)

unread,
Aug 10, 2019, 3:38:02 PM8/10/19
to jenkinsc...@googlegroups.com
FABRIZIO MANFREDI commented on Bug JENKINS-58578
 
Re: Public IP can still be assigned when Associate Public IP is disabled, depending on subnet(s)

You are right we don't force tho disable the ip in case of false, that results in the behavior that you have seen in case the public subnet.

Patch created : https://github.com/jenkinsci/ec2-plugin/pull/387

 

 

egutierrez@cloudbees.com (JIRA)

unread,
Sep 26, 2019, 3:46:05 AM9/26/19
to jenkinsc...@googlegroups.com
Evaristo Gutierrez resolved as Fixed
 
Change By: Evaristo Gutierrez
Status: In Progress Resolved
Resolution: Fixed
Released As: ec-2.46
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

vladislav.naumov@gmail.com (JIRA)

unread,
Oct 2, 2019, 3:15:02 AM10/2/19
to jenkinsc...@googlegroups.com
Vladislav Naumov commented on Bug JENKINS-58578
 
Re: Public IP can still be assigned when Associate Public IP is disabled, depending on subnet(s)

Looks like this patch breaks non-VPC slaves:
no matter if "Associate Public IP" checkbox is set or not, slave fails to launch.
Theres "The AssociatePublicIpAddress parameter is only supported for VPC launches" message in logfile.

Reverting 1.46.1 -> 1.45 fixes the behavior.

yves.schumann@ti8m.ch (JIRA)

unread,
Nov 11, 2019, 5:06:03 PM11/11/19
to jenkinsc...@googlegroups.com

Same here. Need to revert to 1.45 to bring my EC2 builds back to green.

vladislav.naumov@gmail.com (JIRA)

unread,
Jan 20, 2020, 1:00:03 AM1/20/20
to jenkinsc...@googlegroups.com

Problem persists in 1.48, non-VPC slaves can't be launched with same "The AssociatePublicIpAddress parameter is only supported for VPC launches" error message.

Checkbox does nothing.

Reply all
Reply to author
Forward
0 new messages