Remove default security group from EC2-Instance

[elgohr]

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 using aws:autoscaling:launchconfiguration:SecurityGroups (https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalinglaunchconfiguration) the defined groups are added to the EC2-Instance. Nevertheless a default group is also added to the instance. How can this be removed?

Is this request specific to an Elastic Beanstalk platform?
If so, which one(s)? multi-container-docker-18.09.9-ce-(generic)

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.
Security hardening.

Are you currently working around this issue?
How are you currently solving this problem?
No workaround.
Edit 2023-02-05: You could try working around by putting the Beanstalk into a VPC with a private subnet (#44 (comment)).

[karl-cardenas-coding]

I don't understand why a security-group has to be created when we specify our own. From an enterprise perspective, this is often an anti-pattern as Cloud Enablement teams generate approved security groups.

[jbm00n]

If I understand this case correctly, it's not specific to a platform. We faced the same issue with the Java platform.

To work around it we had to implement couple of hacks.

1. Define "AWSEBSecurityGroup: { "CmpFn::Remove" : {} }" within an ebextension, that would remove the extra security group on the fly during deployment.

2. However, later we enabled the EC2 keypair access, and that forces the EB group to stay (previous statement does not work), as it defines the SSH port 22 to be open on all (due to the keypair). The only workaround left is that you can define the IP/group restriction on this port. As we use the keypair for SSH tunneling via SSM, the SSH port is not required at all in our case.

Therefore we set the port 22 "incomings" to the same security group of the EC2 instance (application security group). That limits the port 22 to be used by the EB instances only. (aws:autoscaling:launchconfiguration with OptionName: SSHSourceRestriction)

All in all, I agree that if we specify our own custom security group, EB shouldn't force a default, partly redundant and potentially less secure security group.

[derandreasberger]

Hello, we're seeing the same issue when specifying a EC2-keypair a new AWS generated Security Group gets added which opens Port 22 for 0.0.0.0/0.
This group was not there before and using "https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/community-provided/security-configuration/securitygroup-disable-auto-use-existing.config" approach I would have assumed no new groups get added by such a change.

"All in all, I agree that if we specify our own custom security group, EB shouldn't force a default, partly redundant and potentially less secure security group."
I totally agree.

[ExploHash]

We also have this issue, we currently deploy almost all environments with cloudformation and tried to restrict http access on our development environment. This wasn't possible because the default security groups allows everyone on port 80. Currently fixed it with the above proposal.

[rahulrajaram]

Thanks everybody for voicing your concerns. The default EC2 SG, and the additional EC2 SGs that customers are allowed to pass serve two different purposes. Whereas EB will use the default SG to open it to the LB, the additional SGs customer are allowed to pass are simply attached to the EC2 instances; EB maintains that these SGs will not be manipulated.

So, we cannot simply prevent the default security group from being created because doing so would break backwards compatibility. However, we can possibly look into providing a way for you to direct EB not to create the default SG through an option setting in the aws:autoscaling:launchconfiguration. This would also prevent creation of the default SG if EC2KeyName is specified.

Is this a feasible solution to your problem?

[KasperFranz]

Thanks everybody for voicing your concerns. The default EC2 SG, and the additional EC2 SGs that customers are allowed to pass serve two different purposes. Whereas EB will use the default SG to open it to the LB, the additional SGs customer are allowed to pass are simply attached to the EC2 instances; EB maintains that these SGs will not be manipulated.

So, we cannot simply prevent the default security group from being created because doing so would break backwards compatibility. However, we can possibly look into providing a way for you to direct EB not to create the default SG through an option setting in the aws:autoscaling:launchconfiguration. This would also prevent creation of the default SG if EC2KeyName is specified.

Is this a feasible solution to your problem?

For my use-case that would be a very viable option

[karl-cardenas-coding]

@rahulrajaram yes this would work for my organizations usecase.

[ExploHash]

@rahulrajaram Yes, that would be awesome! Thanks for noticing our concerns

[elgohr]

@rahulrajaram Looks good. The SG is also used in a single instance setup, guess this can be removed then?

[rahulrajaram]

@elgohr , yes, it would make most sense from the usability perspective to keep the behaviour consistent across all types of environments.

[vjsingh]

@rahulrajaram thanks that would solve our problem as well !

Any idea on an ETA? Thank you,

[marns93]

@rahulrajaram it works for our usecases as well. Do you have any updates for us? :)

[E-Rockalanche]

@rahulrajaram This is the solution I've been looking for. That would be awesome

[navaganeshr]

can i know if the new option setting to disable auto-creation of default security group under aws:autoscaling:launchconfiguration is released or not ?

[urkle]

@navaganeshr It seems they did add this (just not documented well) See SSHSourceRestriction in https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalinglaunchconfiguration

[fferreira-lucid]

@urkle I don't think that it's the same.
We're asking them the ability to create EB envs/apps without creating a security group so we can use a pre-existing one managed by ourselves in its place.
What the SSHSourceRestriction does is modify the SSH rules that exists in the SG that EB is going to create during creation-time.

It's a valid workaround IMO, but it still creates a new SG with a some-what random name.

[urkle]

It's a valid workaround IMO, but it still creates a new SG with a some-what random name.

@fferreira-lucid I totaly agree that it is a horrible workaround. IMHO it would be better to have a simple option to DISABLE the SG creation as I couldn't even get the SSHSourceRestriction to work (as it claims to be able to reference an existing SG).. So in the end I just turned off SSH completely for now.

[Nicko-13]

Any updates on this issue? I have created my own security groups for ALB and EC2 and created the stack with CloudFormation template. I need custom security group to allow traffic from EC2 to RDS instance. With this pesky default security group I am not sure that the traffic will go from desired security. For production https can be set, but still having default group is really disappointing

[rahulrajaram]

This is being actively worked on by the team as we speak.

[jameseggers]

Hi @rahulrajaram - do you have any updates here?

[ryota-saito-0309]

Hello I'm looking forward to the update.
@rahulrajaram - Is there an update to the issue?

[brandong954]

This is bananas. How has such a security vulnerability not been resolved yet? At least there's a workaround for port 22 (i.e. SSHSourceRestriction), but there's also port 80, in my case, still being exposed to the outside world for a development server. Please update us on the status @rahulrajaram.

Here's the ebsextension config to restrict port 22 for anyone else in need of it:

option_settings:
  aws:autoscaling:launchconfiguration:
    SSHSourceRestriction: 'tcp, 22, 22, your-custom-sg-id'

[michaelbrewer]

Why would you assume opening port 22 to the world was something you would want to do? Please allow for security groups to be managed separately.

[mdesouky]

I'm surprised to see AWS opening holes in customers security on purpose ? nobody ever thought this was a good idea, at least give us a stack parameter/option to disable it

[michaelbrewer]

@mdesouky - i would recommend never assigning a public ip address to the EC2 instances or assigning a SSH keypair.

Instead, use SSM agent to access the servers via the AWS Console.

[andrius-paurys]

Much needed update - the default rule is a really annoying security pitfall.

[elgohr]

We solved this issue by stopping to use Beanstalk.

[lisenet]

So Beanstalk won't let you select a previous version of a platform calling it a "security risk to our customers", but this is acceptable?

[dgagnon]

@lisenet the recommended setup includes private subnets, which won't allow inbound connections to your instances from the internet. See https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.vpc.html

[lisenet]

@dgagnon but it does allow all outbound traffic to the Internet which is a security risk. How does one remove the default Beanstalk SG?

[dgagnon]

@lisenet The default security group only opens inbound SSH. Outbound is open by default on all security groups.

To completely remove outbound internet access from EB instances, you would need VPC endpoints for every service you use from AWS plus all the updates and packages already built in to your AMI.

EB also allows you to specify specific security groups for LB and instances, you can add restrictions using these.

[elgohr]

@dgagnon where did you get the information that this is the recommended setup?

Didn’t find a word in the security best practices (https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/security-best-practices.html) or general Beanstalk security guidelines (https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/security.html).

I’m sorry, but letting customers tinker custom VPC-solutions to stuff default security holes isn’t my understanding of
Cloud security at AWS is the highest priority.

[dgagnon]

@elgohr that link pertains to the security aspects specific to elastic beanstalk. For VPC related security, you can look at this link: https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html

Edit: I recommend the following guide as well: https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html

[elgohr]

@dgagnon so I'm buying a PaaS solution to patch the IaaS inside the solution? Did I get that correct?

[dgagnon]

@elgohr no you did not.

[lisenet]

@dgagnon

Outbound is open by default on all security groups.

That's precisely the problem. We want to be able to control outbound traffic by using SGs. How is having a default SG that allows all traffic to leave the network best practice?

[dgagnon]

@lisenet If you need that level of security, manage the NAT instances yourself instead of using NAT Gateways. We use pfSense and it works great in that regard. You can even install SSM agent on it although not many of the automations supports FreeBSD properly.

[janzelc-trifecta]

@lisenet If you need that level of security, manage the NAT instances yourself instead of using NAT Gateways. We use pfSense and it works great in that regard. You can even install SSM agent on it although not many of the automations supports FreeBSD properly.

This doesn't resolve the issue. Egress for instances should explicitly defined and that cannot be achieved by using the default security group. It's not just instance traffic egressing to the internet.

[dgagnon]

@janzelc-trifecta see my earlier comments on what is needed to achieve the level of egress control you want. All the tools are there at your disposal for your specific use case. EB is designed with access to internet in mind. From this thread, it seems most people do not even use private subnets. This would make your use case more of an edge case.

I do no know of any compliance framework who forbid internet access completely. Mandate DLP ? Sure. Strict firewalls ? Absolutely. IDS ? ez-pz. no access to the internet of any kind ? what are you doing on EB then ?

While it is possible to completely cut off the access to the internet from your VM, the security group is not where it happens. Use network ACLs and routing tables.

[lisenet]

@dgagnon you are in denial.

[dgagnon]

@lisenet I run a successful business and have many big customers on Elastic Beanstalk, including customers with compliance requirements. But I am also a Certified AWS Cloud Practitioner, I understand the security guarantees of AWS as well as it's capabilities.

Maybe it just is not for you.

[lisenet]

@dgagnon good for you, but neither of that is a justification of the problem reported on this issue I'm afraid.

[dgagnon]

@lisenet The problem reported is easily worked around in less than 15 minutes of work. I have provided many different solutions to the reported problem. The hostility in this thread toward AWS is unwarranted for an issue of this caliber.

[elgohr]

@dgagnon thank you for your suggested workarounds.
As it’s so easy, why not have it as a default (also protecting the non-cloud practitioners)?

[elgohr]

Updated the workaround section in the initial report.

[backnol-aws]

We have decided to halt development of this feature until we can accommodate more complex customer uses cases. We want to ensure that the existing environments continues to operate without disruption.

[RachelNaane]

I also found this very annoying. I have a EB, and the default SG was manualy detached from the ec2s and deleted, and from then on we could not work with the EB as it always looked for a SG with the id of the deleted one and would fail with error.

[CanIGetaPR]

We have decided to halt development of this feature until we can accommodate more complex customer uses cases. We want to ensure that the existing environments continues to operate without disruption.

@backnol-aws Guys, come on the fix is simple and remains backwards compatible. It's a simple flag addition:

option_settings:
  aws:autoscaling:launchconfiguration:
    AutoGeneratedSecurityGroup: false

[CanIGetaPR]

Hey everyone, after trying various options I finally found the solution and it is extremely simple.

What we have to do is tell Cloud Formation to replace the security group resource elastic beanstalk created. The easiest way to do that is by changing the name! And best of all Elastic Beanstalk always assigns the default security group a logical name of AWSEBSecurityGroup so it's easy to do.

Alright here is an example solution:

1. Create the .ebextensions folder in your project directory if you haven't already (same folder you have the .elastbeanstalk folder in).
2. Create a file any name you like that ends in .config. I used securitygroup.config
3. Use the Resources key to specify the AWSEBSecurityGroup resource you'd like to replace with new rules.
   Here's a simple example of replacing the default security group they add which has ports 22, 80, and 443 open with one that only opens port 80 to CloudFront.

Filename: .ebextensions/securitygroup.config

Resources:
  AWSEBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: my-sg
      GroupDescription: Allow CloudFront
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          SourcePrefixListId: pl-4ea04527

The key here is using AWSEBSecurityGroup as the logical resource name, and modifying the GroupName property to trigger replacement. (Yes, this also renames the group from awseb-jioe89erg89ehjf9er8f to your specified name, my-sg in the example.)

-Phew- Sifting through AWS documentation can sure be a woozy.

[rivatove]

Hey everyone, after trying various options I finally found the solution and it is extremely simple.

What we have to do is tell Cloud Formation to replace the security group resource elastic beanstalk created. The easiest way to do that is by changing the name! And best of all Elastic Beanstalk always assigns the default security group a logical name of AWSEBSecurityGroup so it's easy to do.

Alright here is an example solution:

1. Create the .ebextensions folder in your project directory if you haven't already (same folder you have the .elastbeanstalk folder in).
2. Create a file any name you like that ends in .config. I used securitygroup.config
3. Use the Resources key to specify the AWSEBSecurityGroup resource you'd like to replace with new rules.
   Here's a simple example of replacing the default security group they add which has ports 22, 80, and 443 open with one that only opens port 80 to CloudFront.

Filename: .ebextensions/securitygroup.config

Resources:
  AWSEBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: my-sg
      GroupDescription: Allow CloudFront
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          SourcePrefixListId: pl-4ea04527

The key here is using AWSEBSecurityGroup as the logical resource name, and modifying the GroupName property to trigger replacement. (Yes, this also renames the group from awseb-jioe89erg89ehjf9er8f to your specified name, my-sg in the example.)

-Phew- Sifting through AWS documentation can sure be a woozy.

Thanks for the solution. I confirm that it is indeed working.

To block access completely, create an empty security group and assign it to the resource.

Resources:
  AWSEBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: { "Ref" : "AWSEBEnvironmentName" }
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          SourceSecurityGroupId: <SECURITY_GROUP_ID>

Cons:
You need to put this file in source control of every deployed app. This is not ideal.

We still need an option like this one:
#44 (comment)

[CanIGetaPR]

Here's why the security group has such an unattractive name: https://stackoverflow.com/a/56924571/4425643

Because if we give it a pretty static name, cloudformation chokes and can't update our configuration when it needs replacing. https://repost.aws/knowledge-center/cloudformation-custom-name

So in other words, we can't have nice things.

[hchalouati]

The workarounds are not working for SingleInstance EB and we haven't been able to automate the update using Terraform CDK. We finally added instructions to remove the ingress rule manually until finding a way to automate this.