Allow full control of security groups for ApplicationListener

[clstokes]

ApplicationListener seems to have two modes when it comes to security groups:

• If external == true, assume control of the associated load balancer's security groups and open up to the entire public internet. This also sets scheme to internet-facing when calling AWS.
• If external == false, assume no control of the associated load balancer's security group and set scheme to internal.

Part of this logic is at https://github.com/pulumi/pulumi-awsx/blob/a8cab4bd972b4c5bc4112c32f353990003aeb968/nodejs/awsx/elasticloadbalancingv2/application.ts#L222-L234

This does not allow for users to fully control the security groups of their load balancers and forces them to pick one of two options that might not fit their needs.

I suggest that if a security group is provided that it is used without modification. In this scenario, the user should be knowledgable enough to fully control the security group's rules.

Additionally the ApplicationListener modifying the associated load balancer's security groups provides a confusing "misdirection" when trying to understand this behavior. I'd like it if we could separate this somehow so that when a user is working with a ApplicationListener, the scope of what they're working on is clear and constrained.

[ypresto]

It is also problematic because the created security group assumes that a target's port is the same as a listener port, i.e. ingress lb:80 -> egress target:80.

[ypresto]

Additionally the ApplicationListener modifying the associated load balancer's security groups

I actually expect awsx package to hide SecurityGroup as much as possible, like AWS CDK's high-level constructs. We can some options to disable it or https://github.com/pulumi/pulumi-awsx/issues/293#issuecomment-581039110 , or we can use aws package for handcrafting SecurityGroup and etc.

[devgnx]

I need this

[jeanlescure]

I actually expect awsx package to hide SecurityGroup as much as possible

The ethos is fine, but not allowing a way to override is naive and irresponsible, as it narrows the ability to use this library to "happy paths" only since there's no way for you to guess all scenarios your users will try to apply awsx to.

I'm really worried about having picked Pulumi for orchestration for the project my company is working on as we have already invested a lot of time migrating and from what I read there's no workaround to set custom SecurityGroups for our services, which is a must for us.

[PabloJomer]

I need this.