AWS NLB – Configuring Inbound Whitelist IP

amazon-web-services

First of all, I'm newbie with docker-compose and AWS services but I have tried to learn about it and prepare it correctly, any advice is welcome.

I need to publish a app with ECS (this part works well, i use a docker-compose to do it. It publish correctly with a elastic public ip and it works) but the access to the app must be limited by allowed IPs. My idea was to publish the app with a public IP (Elastic IP assigned to load balancer) and limit access by security groups there.

But I can add any type of security group to load balancers, and if I modified security group of my services, they don't work.

My question is, can I assign a whitelist IPs to a NLB? I have seen that I can do like a whitelist IP in ALB but it doesn't assign elastic ip.

Best Answer

Are you publishing a web application / API? If so you should probably use an application load balancer rather than a network load balancer. NLBs are usually used for non-http(s) applications, you can use them with http(s) but ALBs tend to be better suited.

Design Considerations

I suggest you think about whether you really need a static IP. Some legacy or embedded systems might need it, but most are ok with a DNS address. If you really need a static IP you can use one of these techniques (or others you find on Google) to give an ALB a static IP, AWS Global Accelerator would do it but I'm not sure it's a good solution for you. You'd also have to consider high availability.

Regarding static IPs for whitelisting, you could consider doing authentication either with AWS Cognito integrated with the ALB (best) or inside your container. We usually federate with Azure AD, but you can define users / groups in Cognito. Users traffic to the ALB only gets to the target container / server if Cognito authorises the traffic.

Primary recommendation: AWS ALB integrated with AWS Cognito for authentication, security group around the ALB if you like but no whitelisting required.

Original Question

ALBs have security groups. Network load balancers do not. An NLB is invisible to the traffic so you put a security group around your resource (container) rather than your load balancer.

ALB IP whitelisting options:

You can whitelist access to an ALB with a security group, but you can't blacklist with a security group. There's a maximum number of rules, but each ALB can probably have multiple SGs attached - though be careful as it can impact performance. This is my secondary recommendation to you if you don't want to use Cognito.
You can whitelist or blacklist with Network Access Control Lists (NACLs)
You can do something inside the container with a local firewall, but I don't suggest that

NLB IP Whitelisting options:

Security group around the ECS container
NACL around the subnet(s)

Related Solutions

Problems creating AutoScaling Group with a Network Load Balancer (NLB) on AWS using Terraform

Try using the target_group_arns option on the ASG.

resource "aws_autoscaling_group" "asg" {
    name  = "test"
    vpc_zone_identifier = ["${data.aws_subnet.sn-app-1.id}","${data.aws_subnet.sn-app-2.id}"]
    min_size  = 1
    desired_capacity  = 1
    max_size  = 3
    launch_configuration = "${aws_launch_configuration.lc.name}"
    target_group_arns = ["${aws_lb_target_group.lbtg.arn}"]
    default_cooldown= 180
    health_check_grace_period = 180
    termination_policies = ["ClosestToNextInstanceHour", "NewestInstance"]
}

Nginx – How prevent WAF bypass on AWS

Why do you have both an NLB and an ALB?

AWS ALB

AWS Application Load Balancer has security groups (documentation link). You can use that to limit which IPs traffic can from from. That relies on NLB not messing with that information.

AWS NLB

The AWS Network Load Balancer works at Layer 4, and according to Wikipedia "Class 4 is closest to TCP". I wonder if NLB doesn't change the source IP - hopefully someone else who's more familiar with this can answer / comment, it's been a long time since I learned the OSI model. If so this would work well with the ALB security groups.

X-Forwarded-For

Another approach is that Securi most likely sets the X-Forwarded-For header. In Nginx you can use the "real_ip_header" command to say "for the IPa addresses I specify (ie that belong to Securi) the original IP address is in this header". eg:

set_real_ip_from  192.168.1.0/24;
set_real_ip_from  192.168.2.1;
set_real_ip_from  2001:0db8::/32;
real_ip_header    X-Forwarded-For;
real_ip_recursive on;

To be careful of is that the AWS ALB might also set that header, hiding what Securi sets.

Nginx Allow / Deny

Once that's done you have another method using Nginx that lets you block all hosts other than those you allow.

allow 1.2.3.4;   # Allow a single remote host
deny all;        # Deny everyone else

Summary

If you can simplify your architecture you can probably find a simpler solution.

Best Answer

Related Solutions

Problems creating AutoScaling Group with a Network Load Balancer (NLB) on AWS using Terraform

Nginx – How prevent WAF bypass on AWS

Related Topic