Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-58578

Public IP can still be assigned when Associate Public IP is disabled, depending on subnet(s)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • ec2-plugin
    • None
    • 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
    • ec-2.46

      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.

      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 would propose something like the following:

      For "Associate Public IP", utilize a drop-down menu similar to the one in the AWS console itself, which has three options: Use subnet setting (default), Yes, and No. When "No" is selected, explicitly pass in false. Perhaps use an enum for this, similar to ConnectionStrategy.

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

          Andrew Goldin created issue -
          Andrew Goldin made changes -
          Description Original: 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}}.
          New: 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.
          Andrew Goldin made changes -
          Description Original: 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.
          New: 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.
          Andrew Goldin made changes -
          Description Original: 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.
          New: 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.
          Andrew Goldin made changes -
          Description Original: 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.
          New: 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:
           # 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.
          Andrew Goldin made changes -
          Description Original: 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:
           # 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.
          New: 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 would propose something like the following:

          For "Associate Public IP", utilize a drop-down menu similar to the one in the AWS console itself, which has three options: Use subnet setting (default), Yes, and No. When "No" is selected, explicitly pass in {{false}}. Perhaps use an enum for this, similar to ConnectionStrategy.

          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

           

           

          FABRIZIO MANFREDI added a comment - 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    
          FABRIZIO MANFREDI made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Evaristo Gutierrez made changes -
          Released As New: ec-2.46
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]

          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.

          Vladislav Naumov added a comment - 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.

            thoulen FABRIZIO MANFREDI
            andgoldin Andrew Goldin
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: