Cloudformation-coverage-roadmap: AWS::ElasticLoadBalancingV2::LoadBalancer-GetAtt-IpAddressList

Created on 18 Dec 2019  路  6Comments  路  Source: aws-cloudformation/cloudformation-coverage-roadmap

Scope of request

Category: e) other coverage-related issue with the resource/attribute/option

  • Ability to determine or specify private IP addresses used for an NLB
  • Proposed solutions:

    1. Attribute to return a list of IP addresses for an NLB

    2. Ability to use specific AWS::EC2::NetworkInterface resources for the NLB ENIs, giving known/query-able IP addresses

    3. Implement the PrivateIPv4Address property of SubnetMapping in the CreateLoadBalancer API call as part of AWS::ElasticLoadBalancingV2::LoadBalancer SubnetMapping, allowing specification of fixed IP addresses

Expected behavior

Option i. (Attribute to return a list of IP addresses for a load balancer)

  • Fn::GetAtt for IpAddressList returns a comma-separated list of IP addresses for the NLB

    • This assumes the IP addresses are static

  • IP addresses can be extracted with Fn::Split and used in AWS::EC2::SecurityGroupIngress resources

    • Assumes number of Subnets (i.e. number of IP addresses) is known or can be inferred

Option ii. (Ability to use specific AWS::EC2::NetworkInterface resources for the NLB ENIs)

  • Create one or more AWS::EC2::NetworkInterface resources
  • New property of AWS::ElasticLoadBalancingV2::LoadBalancer allows specifying pre-existing ENIs

    • I can't see a way to do this with the ElasticLoadBalancingV2 API, so this would require an extension to that API

  • IP addresses can be retrieved with Fn::GetAtt for PrimaryPrivateIpAddress and used to in AWS::EC2::SecurityGroupIngress resources

Option iii. (Implement SubnetMapping PrivateIPv4Address property)

  • Add a PrivateIPv4Address property to the AWS::ElasticLoadBalancingV2::LoadBalancer SubnetMapping object, mapping to PrivateIPv4Address in SubnetMapping for the CreateLoadBalancer call

    • Requires specifying unused IP addresses manually somehow

Suggest specific test cases

Common use case:

  • NLBs perform Health Checks against targets from the NLB node IP addresses
  • As NLB nodes / ENIs themselves do not have Security Groups, the NLB node IP addresses must be allowed in the target ingress rules
  • There's currently no way to get these IP addresses, forcing one of the following 3 workarounds:

    1. Populate manually after NLB creation



      • Forces manual/human-driven deployment steps



    2. Allow entire subnet



      • Security risk


      • Hypothetical example: HTTP API service, with an APIGateway-VPCLink-NLB construction for ingress and using the API GW for key authentication etc


      • Allowing the entire subnet access to the targets would give other applications in the VPC direct access to this API, bypassing the API GW



    3. Construct custom resource to infer NLB IP addresses from ENI descriptions



      • Complex solution


      • Relies upon ENI description strings to find those used for the NLB, and this would break if the string changed



Helpful Links to speed up research and evaluation

(Mostly applicable to Option iii.)

Category

  1. Compute (EC2, ECS, EKS, Lambda...)
  2. Networking & Content (VPC, Route53, API GW,...)
networking & content deliv

Most helpful comment

I'd like to see this implemented, and I'd suggest the path (iii) (adding a PrivateIPv4Address to SubnetMappings) is the way to go, since it would behave as the APIs

All 6 comments

if i have 100 thumbs i will throw all of them to thumb this up. in the past 12 months i have to deploy the custom resources at least 8 times for multiple client. i would like to have a proper native solution than a custom hack from custom resources

I'd like to see this implemented, and I'd suggest the path (iii) (adding a PrivateIPv4Address to SubnetMappings) is the way to go, since it would behave as the APIs

+1 for the (iii) option.

Using NLB for Radius or NB-IOT NIDD applications, which require putting IP addresses in config (and not hostnames).

+1 for the (iii) option.

I'm using an NLB for capturing syslog data from on-prem devices. Since these devices are difficult to update I prefer to choose a static IP address in advance and assign it to the NLB.

+1 for all of these options. I think (i) is still required even if (ii) or (iii) are available as I'd still want to list IPs even if I haven't pre-defined them.

Also worth referencing the AWS documentation for Registering Targets with Your Target Group, which details the comically manual steps required to restrict healthchecks to LB private IPs:

If you do not want to grant access to the entire VPC CIDR, you can grant access to the private IP addresses used by the load balancer nodes. There is one IP address per load balancer subnet. To find these addresses, use the following procedure.

To find the private IP addresses to whitelist

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. In the navigation pane, choose Network Interfaces.

  3. In the search field, type the name of your Network Load Balancer. There is one network interface per load balancer subnet.

  4. On the Details tab for each network interface, copy the address from Primary private IPv4 IP.

Reviewing this again today in light of a new application requirement, and I noticed it is now possible to specify PrivateIPv4Address in SubnetMappings. In fact, this was silently added to the docs on 2020-06-18.

This satisfies my use-case, but leaving this issue open as some have pointed out that suggested resolution (i) is still necessary.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

luiseduardocolon picture luiseduardocolon  路  4Comments

ghost picture ghost  路  4Comments

tortila picture tortila  路  3Comments

hoegertn picture hoegertn  路  4Comments

grauj-aws picture grauj-aws  路  3Comments