EB Managed security groups for ALB's have ALL (0.0.0.0/0) addresses allowed instead of instance security groups as target.

CmhDevFor commented 3 months ago

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments. They generate extra noise for issue followers and do not help prioritize the request.

Tell us about your request When creating an elastic beanstalk environment configured with a shared application load balancer, the environment creates a managed security group (SG_LB) on the load balancer with the below rules and a second security group for the instances (SG_IN)

The current SG_LB rules allow all traffic from the load balancer to go anywhere. For an internet facing load balancer this is unacceptable. See AWS guidelines (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-update-security-groups.html)

Current Generated Rules

SG_LB Inbound Rules: None (It rightly assumes a shared load balancer has a default group with ingress port rules already) Outbound Rules:	Name	Security Group Rule ID	IP version	Type	Protocol	Port range	Destination
-	sgr-xxxxxx	IPv4	All traffic	All	All	0.0.0.0/0
-	sgr-yyyyy	IPv4	HTTP	TCP	80	0.0.0.0/0

SG_IN Inbound Rules:	Name	Security Group Rule ID	IP version	Type	Protocol	Port range	Source
-	sgr-xxxxxx	-	HTTP	TCP	80	_SG_LB_

What SG_LB should be

Outbound Rules (Example has an elastic beanstalk instance port 80 set, but this should be an entry for each port specified in the environment configuration for instances):	Name	Security Group Rule ID	IP version	Type	Protocol	Port range	Destination
-	sgr-yyyyy	IPv4	HTTP	TCP	80	_SG_IN_

Is this request specific to an Elastic Beanstalk platform? If so, which one(s)? Any environment with a shared load balancer configuration

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem. This is a default configuration issue. It can be manually corrected but should be fixed in EB.

Are you currently working around this issue? How are you currently solving this problem? Manually editing rules.

Additional context Anything else we should know?

Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

jceduar commented 3 months ago

Hello @CmhDevFor , In efforts to provide additional insight, the following AWS Elastic Beanstalk documentation ("Configuring a shared Application Load Balancer") provides insight regarding the expected behavior when using a Shared Application Load Balancer and Security Groups. It is important to note that you are always given the option to configure your own security groups to use for the Shared Application Load Balancer. The Elastic Beanstalk service during environment creation validates whether you have supplied your own or not. If you don't configure your own security group, Elastic Beanstalk as a courtesy will check whether an existing security group that Elastic Beanstalk manages is already attached to the load balancer. If not, Elastic Beanstalk creates a security group on your behalf and attaches it to the load balancer. Elastic Beanstalk deletes this security group when the last environment sharing the load balancer terminates. Furthermore, you are correct such that the managed security group that Elastic Beanstalk created on your behalf does not have implied outbound rules with the destination being the EC2 security group for the environments that are provisioned to use the Shared Load Balancer. As well, the default destination allows all outbound on (0.0.0.0/0). However, it is important to understand other limitations exists such as VPC Security Group - Quotas in regards to ("Inbound or Outbound rules per security group") as shown in the VPC Quota documentation:

[Name]: Inbound or outbound rules per security group
[Default]: 60
[Adjustable]: Yes
[Comments]:
This quota is enforced separately for inbound and outbound rules. 
For an account with the default quota of 60 rules, a security group can have 60 inbound rules and 60 outbound rules. 
In addition, this quota is enforced separately for IPv4 rules and IPv6 rules. 
For an account with the default quota of 60 rules, a security group can have 60 inbound rules for IPv4 traffic and 60 inbound rules for IPv6 traffic.

As a result, the managed security group that Elastic Beanstalk creates on your behalf as courtesy when one is not already supplied can cause issues for users who create 60+ environments using the same Shared Load Balancer under the circumstance the service created an implied outbound rule for each environment. As a result, allowing all outbound on (0.0.0.0/0) for the managed security group is the most flexible approach to ensure environment creation failures are avoided due to the referenced quota limit. Next, I would still highly recommend that you use your own security group with the Shared Application Load Balancer so it can be customized to your own desired specifications. If you would like to dynamically add an implied outbound rule the your own security group with the destination being the EC2 security group for your environment then using an .ebextensions configuration file would be the solution.

The following .ebextensions configuration files was tested in my own environment. I would ask you to update the sg-xxxx value with your own that is already attached to the Shared Load Balancer:

option_settings:
  aws:elbv2:loadbalancer:
    ManagedSecurityGroup: "sg-xxxx"  
    SecurityGroups: "sg-xxxx"

Resources:
  SharedLoadBalancerEgress:
    Type: AWS::EC2::SecurityGroupEgress
    DependsOn: AWSEBSecurityGroup
    Properties:
      GroupId: "sg-xxxx"
      IpProtocol: tcp
      FromPort: 80
      ToPort: 80
      DestinationSecurityGroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}

Overall, I would like to note that the AWSEBManagedLBSecurityGroup resource will remain on the Shared Load Balancer until Elastic Beanstalk deletes this security group when the last environment sharing the load balancer terminates. As a result, if you decide on your own accord to manually delete it.. I would ask you to ensure all of your environments are not impacted by first applying the solution to the environment with the valid rules. Lastly, the above solution can be updated to your own requirements whether HTTP/80 or HTTPS/443, etc..

Hope it helps!

References: [1] Configuring a shared Application Load Balancer - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-alb-shared.html#environments-cfg-alb-shared-intro [2] How do I use my own security group for my load balancer when I deploy an Elastic Beanstalk application? - https://repost.aws/knowledge-center/security-group-elastic-beanstalk [3] Namespace (aws:elbv2:loadbalancer) - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-elbv2 [4] Advanced environment customization with configuration files (.ebextensions) - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html

CmhDevFor commented 3 months ago

When I originally told it to use my own supplied security group, it properly attached mine, but also added the managed one with full outbound for the first environment. I have not tried again since so maybe this bug was corrected.

Would it not be possible to add a second managed group for those that have 60+ environments? Forcing people to either have it fully open OR figure out the bootstrapping and remember to remove the default one that is attached seems the least desirable outcome considering I imagine there are more people who have < 60 environments, rather than just 1) Detecting the environments will be >60 and making a second managed group OR 2) Making a managed group specific to each environment if one is not specified.

Having any default behavior be full allow connected to a resource which is allowed traffic in from the internet is a recipe for mistakes even when you have customizations that can mitigate it.

Edit: Thank you for the surprisingly thorough answer. I appreciate it.

jceduar commented 3 months ago

Hello @CmhDevFor ,

Thanks for your understanding! I try my best to provide some assistance when possible and hope to bring clarification as I enjoy using this service but there is always room for good ideas and/or solutions to uncover!

Question # 1:

"When I originally told it to use my own supplied security group, it properly attached mine, but also added the managed one with full outbound for the first environment. I have not tried again since so maybe this bug was corrected."

Response: In my testing yesterday, I believe this may be encountered when only one of the Namespace (aws:elbv2:loadbalancer) options such as ManagedSecurityGroup or SecurityGroups is used rather than both being included in the .ebextensions configuration file. I would not be able to confirm whether this has change since your last attempt but it certainly worked in my testing with both being included yesterday!

Question # 2: "Would it not be possible to add a second managed group for those that have 60+ environments? Forcing people to either have it fully open OR figure out the bootstrapping and remember to remove the default one that is attached seems the least desirable outcome considering I imagine there are more people who have < 60 environments, rather than just

Detecting the environments will be >60 and making a second managed group OR
Making a managed group specific to each environment if one is not specified.

Having any default behavior be full allow connected to a resource which is allowed traffic in from the internet is a recipe for mistakes even when you have customizations that can mitigate it."

Response: In my opinion, the main purpose with using a Shared Application Load Balancer with Elastic Beanstalk is to have more control and management over it. While the re-usability feature with multiple environments introduces a cost saving factor as an additional benefit.

Since the Shared Application Load Balancer has to be created first in order for it to be used with an environment. The responsibility falls on the user to ensure all proper components or properties meet their desired requirements or specifications.

The managed security group (AWSEBManagedLBSecurityGroup) resource is added as a safeguard using a flexible approach to ensure connectivity exists and ensures functionality between the infrastructure resources during the environment creation process in the event a user does not supply their own.

In addition, it avoids encountering the "Chicken or the egg" dilemma as when a user does supply their own security group.. they are unaware of the environments EC2 security group as it has not been created or does not exists yet. Hence, the .ebextensions configuration file solution come into the picture to circumvent the managed security group being added. However, I agree there is room for improvement with the documentation to provide guidance and insight on this topic.

Lastly, an Application Load Balancer resource is limited up to 5 security groups. As a result, adding a specific managed security group for each environment or creating a secondary managed security group to over come the quota limit to the load balancer would quickly reach a limitation in this aspect. Also, it opens additional complexity such as a user may not want all of their available/open security groups spots to be used by the service for various reasons so accommodation for all use-cases needs to be considered.

Overall, I hope the above is helpful and it assists others as well!

aws / elastic-beanstalk-roadmap