Unable to create external network load balancer in DMZ with Firewall vpce.

[adamdonahue]

Describe the bug We require an external network load balancer in a DMZ subnet that does not have an IGW, but does have a route to Amazon's Firewall endpoint, effectively allowing external access to the load balancer.

Instead of a route table that routes 0.0.0.0/0 to an IGW, it instead routes to Amazon's Firewall VPC endpoint. Nonetheless, the load balancer should be external (have a public IP).

The AWS console itself also warns us that the DMZ is not "public," but nonetheless still allows us to manually create the network load balancer as internet-facing. Is there a way to force such creation via a Load Balancer Service with an appropriate annotation?

Thanks.

[kishorj]

@adamdonahue what is your workflow when you provision the NLB manually or outside of the LB controller?

[adamdonahue]

We've actually never done that -- but generally I suppose we'd have to expose the service as a NodePort and manually add and manage hte nodes in a target group? I am going to try setting the subnets specifically (with the right tags) and see if that is a workaround.

I'm not sure this qualifies as a "bug" or a "feature request". :)

[adamdonahue]

Unfortunately even after applying the appropriate labels to the DMZ subnets and then specifying them on Service object, we still receive an error that no subnets are available.

[adamdonahue]

I see this code block in several places:

        for _, route := range subnetTable.Routes {
        // There is no direct way in the AWS API to determine if a subnet is public or private.
        // A public subnet is one which has an internet gateway route
        // we look for the gatewayId and make sure it has the prefix of igw to differentiate
        // from the default in-subnet route which is called "local"
        // or other virtual gateway (starting with vgv)
        // or vpc peering connections (starting with pcx).
        if strings.HasPrefix(aws.StringValue(route.GatewayId), "igw") {
            return true, nil
        }
    }

And perhaps this is "correct" in the sense that this is what Amazon considers a public subnet, but that's a fishy distinction when a network firewall is defined.

In any case, I don't see this changing soon -- so I'm going to close this out, and we'll create a NodePort service and route to the EKS nodes via a manually-managed NLB. Bleech.

[kishorj]

@adamdonahue, the code block is from the in-tree controller, not this project. For the external lb controller, we distinguish subnets based on the subnet tags.

In your case, if specifying custom subnets help your case, then you can apply the annotation service.beta.kubernetes.io/aws-load-balancer-subnets. For details, refer to the live docs.

[adamdonahue]

I tried and that it didn't seem to address our use case. To be clear, this should be an external (internet facing) load balancer that exists in a subnet without an IGW (because that subnet is in a DMZ).

[adamdonahue]

Any update here? Is there a way to force the controller to (try to) create an internet-facing load balancer even if a subnet does not have an IGW attached? If not, can we get this as a feature?

[adamdonahue]

I'm going to close this out and try a simpler test with an ingress based on this controller, see if it still raises an issue if we try to put an internet-facing load balancer in a DMZ.

Thanks for the feedback.