Terraform-provider-aws: EB Environment - Override Automatic Security Group Creation

[stevegroner]

Issue or not! I want to provide a custom security group to the Elastic Beanstalk Environment Resource. I can add a setting to make provide a security group for the ELBv2, but for some reason I do not see a place to provide a security group for Elastic Beanstalk Environment itself. It creates the following Security group "awseb-e-xxxxxxxx-stack-AWSEBSecurityGroup-YYYYYYYYYY". I want to provide the Security Group to the resource and not have it auto create. Is there a way to do this?

0.9.11

Affected Resource(s)

Please list the resources as a list, for example:

• aws_elastic_beanstalk_environment

Terraform Configuration Files

N/A

Debug Output

N/A

Panic Output

N/A

Expected Behavior

I would expect there to be a SecurityGroups or ManagedSecurity Group setting for the EB Environment itself so I can provide the group to use instead of having the resouce create it automatically.

Actual Behavior

For the Environment it creates the SecurityGroup on its own each time.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply using the aws_elastic_beanstalk_environment

Important Factoids

N/A

References

N/A

[RyanJarv]

Hey,
Terraform is just an abstraction for the AWS API. Since this isn't exposed directly in the AWS API terraform doesn't really know anything about security groups used for Beanstalk.

However.. aws_elastic_beanstalk_environment does expose setting blocks (https://www.terraform.io/docs/providers/aws/r/elastic_beanstalk_environment.html#option-settings) which allow you pass various options to Beanstalk.

Since these settings aren't known to Terraform or the AWS API they are documented at https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html. I would just search that page for "SecurityGroup" to see what options you have. But it would probably look something like this:

resource "aws_elastic_beanstalk_environment" "tfenvtest" {
  name                = "tf-test-name"
  application         = "${aws_elastic_beanstalk_application.tftest.name}"
  solution_stack_name = "64bit Amazon Linux 2015.03 v2.0.3 running Go 1.4"

  setting {
    namespace = "aws:elbv2:loadbalancer"
    name      = "SecurityGroups"
    value     = "sg-111111111,sg-2222222"
  }
}

Hope that helps

[stevegroner]

Ok, great I will give that a try.

---

From: Ryan Gerstenkorn [e-mail]
Sent: Sunday, October 22, 2017 8:45 AM
To: terraform-providers/terraform-provider-aws
Cc: stevegroner; Author
Subject: Re: [terraform-providers/terraform-provider-aws] EB Environment - Override Automatic Security Group Creation (#2002)

Hey.
Terraform is just an abstraction for the AWS API. Since this isn't exposed directly in the AWS API terraform doesn't really know anything about security groups used for Beanstalk.

However.. aws_elastic_beanstalk_environment does expose setting blocks (https://www.terraform.io/docs/providers/aws/r/elastic_beanstalk_environment.html#option-settings) which allow you pass various settings to Beanstalk.

AWS: aws_elastic_beanstalk_environment - Terraform by ...https://www.terraform.io/docs/providers/aws/r/elastic_beanstalk_environment.html#option-settings
www.terraform.io
»Argument Reference The following arguments are supported: name - (Required) A unique name for this Environment. This name is used in the application URL

Since these settings aren't known to Terraform or the AWS API they are documented at https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html. I would just search that page for "SecurityGroup" to see what options you have. But it would probably look something like this:

resource "aws_elastic_beanstalk_environment" "tfenvtest" {
name = "tf-test-name"
application = "${aws_elastic_beanstalk_application.tftest.name}"
solution_stack_name = "64bit Amazon Linux 2015.03 v2.0.3 running Go 1.4"

setting {
namespace = "aws:elbv2:loadbalancer"
name = "SecurityGroups"
value = "sg-111111111,sg-2222222"
}
}

Hope that helps

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/terraform-providers/terraform-provider-aws/issues/2002#issuecomment-338487179, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ARDt544JAl0V8tICwMyzP-9YJF-N5zqqks5su2MEgaJpZM4QBz4q.

[samnang]

I tried from what @RyanJarv, but it didn't work. It's always appended and keep the default auto-generated one.

[RyanJarv]

@samnang yes, that's expected. The autogenerated one is the ManagedSecurityGroup which is managed separately.

Edit: Reread the original issue, probably should have mentioned this before (sorry!)

[JeremyCraigMartinez]

The auto generated security group awseb-e-ksIkjskllakud-stack-AWSEBSecurityGroup-2DCLLKS98DIKS adds an inbound rule that allows ssh from any origin SSH(22) | TCP (6) | 22 | 0.0.0.0/0. This renders it unusable from a security standpoint. So the expected behavior is to ignore basic security standards?

[JeremyCraigMartinez]

Or can we add a setting block for ManagedSecurityGroup? Like

  setting {
    namespace = "aws:elbv2:loadbalancer"
    name      = "ManagedSecurityGroups"
    value     = ""
  }

[RyanJarv]

So the expected behavior is to ignore basic security standards?

Yeah, I don't like this behavior either. When I ran into it I set it to a nonsensical address/port as a workaround, something like localhost and a random port.

[stevegroner]

Yeah, obviously the request is not to bypass security standards, we will be adding our own security groups and managed security group that contains what we choose, without having the forced port 22. I since have spoken with AWS about this and their API, always creates this security group even when you overload with an option setting. They do have backlog to correct this issue, but it has not yet been solved that I can find. They suggested using an EB extension to remove the AWS created security group. Just an update.

[JeremyCraigMartinez]

Wow, this is pretty absurd.. thank you for the prompt responses. If any of you have implemented an .ebextensions for this or know of a good example out there could you link it here?

[stevegroner]

I guess I might have worded that a little bit incorrect. Here is the exact response from AWS.

To recap our chat, you were looking for a way to avoid creation of the default AWSEBSecurityGroup resource, and to instead assign to your instances an existing security group.

Currently this is not directly feasible through option settings alone. While you can use option settings under the "aws:autoscaling:launchconfiguration" namespace to set additional, existing SecurityGroups, this does not delete the existing AWSEBSecurityGroup resource.

• See SecurityGroups option setting here, http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalinglaunchconfiguration

One option then is to use Custom Resource sections in .ebextensions/*.config files to update the environment's underlying CloudFormation stack. For an existing stack it is not possible to remove completely the AWSEBSecurityGroup resource, but you can customize the AWSEBAutoScalingLaunchConfiguration resource to only use your existing security group(s). You can also customize the AWSEBSecurityGroup resource to add or remove rules.

• More on Custom Resource definitions here, http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-format-resources-eb.html

After our chat, I did find that if you use this ebextension during environment creation, it is possible to prevent the AWSEBSecurityGroup resource from creating. Note this ebextension only works if included in the application version during environment creation:

• Example ebextension here, https://github.com/awslabs/elastic-beanstalk-docs/blob/master/configuration-files/community-provided/security-configuration/securitygroup-disable-auto-use-existing.config

I've submitted a feature request to make this easier through option settings alone, and to make it possible on existing environments in the future. Please let me know if you have further questions.

[JeremyCraigMartinez]

So if all you want to do to remove the AWSEBSecurityGroup is

Resources:
  AWSEBSecurityGroup: { "CmpFn::Remove" : {} }

When considering the entire example, there is no way to automate this with terraform you have to manually add the security group id's

replace with your own SG (supports a list in the "sg1,sg2,sg3", as well as single value "sg"

Which are dynamically created by terraform..

[JeremyCraigMartinez]

Mine is a specific use-case, but one that I imagine everyone else would need to mimic. I just needed to get rid of the default sg adding ssh access from 0.0.0.0/0. I finally got this working with the help of Shawn's answer on an AWS Forum

I removed the keyname pair from my terraform

-  setting {
-    namespace = "aws:autoscaling:launchconfiguration"
-    name      = "EC2KeyName"
-    value     = "${var.ssh_key_name}"
-  }

and instead added it in my .ebextensions. This prevented the default security group from having that ingress rule of 22 on any ip

Resources:
  AWSEBAutoScalingLaunchConfiguration:
    Properties:
      KeyName:  <your key name>

[JeremyCraigMartinez]

Why AWS thinks it's okay to open up ssh access to every IP is beyond me 🤦‍♂️

[evbo]

@JeremyCraigMartinez using terraform 0.11.7 I was just able to create a new eb with a custom ssh source set to my own security group so that ssh is not open to the world.

Try something like this out:

# prevents the eb "environment" security group from being automatically generated, which insecurely allows ssh to the open internet
  setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name      = "SSHSourceRestriction"
    value     = "tcp,22,22,${here I used my own ssh security group name}"
  }

[gazoakley]

@JeremyCraigMartinez - I'd hoped this would work, but instead it just adds the same security group twice and the auto generated one:

Resources:
  AWSEBSecurityGroup: { "CmpFn::Remove" : {} }
  AWSEBAutoScalingLaunchConfiguration:
    Properties:
      SecurityGroups: [
        {
          "Fn::GetOptionSetting": {
            Namespace: "aws:autoscaling:launchconfiguration",
            OptionName: "SecurityGroups",
            DefaultValue: ""
          }
        }
      ]

I'm not sure how that example is supposed to work - it doesn't seem to stop the security group being created either.

[JeremyCraigMartinez]

@gazoakley it's been a while since I was dealing with this, but I believe I solved that issue by an ssh security group to my terraform similar to how @evbo explained, then added a appdeploy hook to the eb

  /opt/elasticbeanstalk/hooks/appdeploy/post/99_revoke_allow_all_ssh_sec_rule.sh:
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/usr/bin/env bash
      aws configure set region us-west-2
      SECURITY_GROUP_ID=$(aws ec2 describe-security-groups \
                          --filters Name=ip-permission.from-port,Values=22 \
                                    Name=ip-permission.to-port,Values=22 \
                                    Name=ip-permission.cidr,Values='0.0.0.0/0' \
                                    Name=tag-key,Values='aws:cloudformation:logical-id' \
                                    Name=tag-value,Values='AWSEBSecurityGroup' --query 'SecurityGroups[*].{Name:GroupId}' | jq '.[0].Name' -cr)
      aws ec2 revoke-security-group-ingress --group-id $SECURITY_GROUP_ID  --protocol tcp --port 22 --cidr 0.0.0.0/0 || true

Note: the || true ensure that on subsequent runs, the already removed security group doesn't cause this command to fail. Hope this helps.

If this looks very alien to you, read up on .ebextensions and platform hooks

[sgript]

Any workarounds for this found? I'm having this issue for TCP/HTTP traffic, a default source of 0.0.0.0/0 is being assigned, when I do not want this.

[sgript]

cc @JeremyCraigMartinez @stevegroner @gazoakley

[varun7447]

@sgript Here is a sample https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/security-configuration/ssh-sourcerestriction.config

[napalm684]

@JeremyCraigMartinez Have you verified that the keypair can be set via ebextension? It appears for Windows at least this is not working.

It might be a bit of a "hack" but I did find a way around port 22 being able to do anything but still having the key pair in terraform:

# Used to create an empty security group.  To specify the key pair
# on a Windows instance (needed for RDP password), it is necessary
# to specify it with the beanstalk settings.  However port 22 is
# automatically opened to all source.  Pointing it to an empty SG
# renders it effectively disabled.
resource "aws_security_group" "sshrestrict" {
  name = "ssh-restrict"
  description = "Restrict SSH access sources to an empty SG"
  vpc_id = "xxxx"
}

# In environment settings for beanstalk
setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name      = "SSHSourceRestriction"
    value     = "tcp,22,22,${aws_security_group.sshrestrict.id}"
  }

[navreddy36]

Mine is a specific use-case, but one that I imagine everyone else would need to mimic. I just needed to get rid of the default sg adding ssh access from 0.0.0.0/0. I finally got this working with the help of Shawn's answer on an AWS Forum

I removed the keyname pair from my terraform

-  setting {
-    namespace = "aws:autoscaling:launchconfiguration"
-    name      = "EC2KeyName"
-    value     = "${var.ssh_key_name}"
-  }

and instead added it in my .ebextensions. This prevented the default security group from having that ingress rule of 22 on any ip

Resources:
  AWSEBAutoScalingLaunchConfiguration:
    Properties:
      KeyName:  <your key name>

@stevegroner @RyanJarv Can you give me an example to override Elastic beanstalk default security group or add existing security group and delete default using terraform.

[stevegroner]

I found no way to override creation of the security group but here is how you can lock it down.

setting {
namespace = "aws:autoscaling:launchconfiguration"
name = "SSHSourceRestriction"
value = "tcp,22,22,127.0.0.1/32"
}

From: navreddy36 [mailto:[email protected]]
Sent: Thursday, March 28, 2019 8:02 PM
To: terraform-providers/terraform-provider-aws [e-mail]
Cc: Groner, Steve (CAI - Irvine) [e-mail]; Mention [e-mail]
Subject: Re: [terraform-providers/terraform-provider-aws] EB Environment - Override Automatic Security Group Creation (#2002)

Mine is a specific use-case, but one that I imagine everyone else would need to mimic. I just needed to get rid of the default sg adding ssh access from 0.0.0.0/0. I finally got this working with the help of Shawn's answer on an AWS Forumhttps://urldefense.proofpoint.com/v2/url?u=https-3A__forums.aws.amazon.com_thread.jspa-3FthreadID-3D231044&d=DwMFaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=ApNtGl6CW3_Pv18_pu6Y_lIBdHrg_hbE4vBgKHhSnxE&s=tIaBFM-l4wBvBvV70-le0bpLRnC5sIw0DFBDaM4SDKo&e=

I removed the keyname pair from my terraform

• setting {

• namespace = "aws:autoscaling:launchconfiguration"

• name = "EC2KeyName"

• value = "${var.ssh_key_name}"

• }

and instead added it in my .ebextensions. This prevented the default security group from having that ingress rule of 22 on any ip

Resources:

AWSEBAutoScalingLaunchConfiguration:

Properties:

  KeyName:  <your key name>

@stevegronerhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stevegroner&d=DwMFaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=ApNtGl6CW3_Pv18_pu6Y_lIBdHrg_hbE4vBgKHhSnxE&s=GJvlsyctwiPf18zeAamJ8Cd0bxylo9MgFYLm_z3O1n4&e= @RyanJarvhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_RyanJarv&d=DwMFaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=ApNtGl6CW3_Pv18_pu6Y_lIBdHrg_hbE4vBgKHhSnxE&s=XVHo-c-5PZw7cijUF6cdbMTfY-NqpBKyzOCX-M8QTfU&e= Can you give me an example to override Elastic beanstalk default security group or add existing security group and delete default using terraform.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_2002-23issuecomment-2D477848482&d=DwMFaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=ApNtGl6CW3_Pv18_pu6Y_lIBdHrg_hbE4vBgKHhSnxE&s=eyO5HJLHZdOo3UbF1GoQz2_fF4jmWH5Jsc1ar_xvZmc&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARDt53ZdFy1GEWdFr4G1JdOtxCSlzRzIks5vbYIqgaJpZM4QBz4q&d=DwMFaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=ApNtGl6CW3_Pv18_pu6Y_lIBdHrg_hbE4vBgKHhSnxE&s=IT_vYLAm4WqbZObeDTszrM2yXBOXbhZI53_t27ch9Qs&e=.

[navreddy36]

@stevegroner, yes you're right but my port is opened for 80 not SSH 22.

[stevegroner]

You can take a look at this. But it is through ebextensions.

https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/community-provided/security-configuration/securitygroup-disable-auto-use-existing.config

From: navreddy36 [mailto:[email protected]]
Sent: Thursday, March 28, 2019 8:26 PM
To: terraform-providers/terraform-provider-aws [e-mail]
Cc: Groner, Steve (CAI - Irvine) [e-mail]; Mention [e-mail]
Subject: Re: [terraform-providers/terraform-provider-aws] EB Environment - Override Automatic Security Group Creation (#2002)

@stevegronerhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stevegroner&d=DwMCaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=DnCHM2IKWNRYjCX-gIr9DbM9EUypMtDTrJRb4heE_60&s=V9vMHzqfVzcjqjQM4Hscjhz5q_ehdrZzkyiLRrmTXII&e=, yes you're right but my port is opened for 80 not SSH 22.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_2002-23issuecomment-2D477852790&d=DwMCaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=DnCHM2IKWNRYjCX-gIr9DbM9EUypMtDTrJRb4heE_60&s=MbLeLitBJ-Dcxkj9GiWk0YrdVH3vnyUdh5QIW6ucNz0&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARDt5wXzeotQQ7uuh2r38s-2DEYlKSUIMNks5vbYfjgaJpZM4QBz4q&d=DwMCaQ&c=hrETxhO8sRCXAcJITi-bu62jJ43QQVS6-BatTNT-3bs&r=JZoCqLZOzsm73iXiqyaXqcpdlwmRmHUooMCsQpU5HoI&m=DnCHM2IKWNRYjCX-gIr9DbM9EUypMtDTrJRb4heE_60&s=-PGcpvbtbHTM2EY1xtGPiiFH0qnPG64EwEzNvox-EB8&e=.

[nywilken]

Folks, thanks for your help with this issue. After looking into this further I found that this level of granularity is not supported by the API as there is no support for specifying the Resources attributes. There are a few settings under the aws:autoscaling:lauchconfiguration namespace that allow for associating existing security groups or restricting the SSH access to a particular CIDR. But those settings do not affect the default elastic beanstalk created resources.

At this time I recommend that you open a ticket with your AWS TAM requesting support for managing default security groups via the API. You may also want to take a look at this example configuration https://github.com/awsdocs/elastic-beanstalk-samples/blob/7af44e03e42ba242a4732890f40794597a1a11f7/configuration-files/community-provided/security-configuration/securitygroup-disable-auto-use-existing.config for help with using a custom security configuration. I've not tried it nor can I can confirm that it works as documented by it appears to be inline with the AWS provided documentation.

I'm going to close this issue as there is nothing for us to do at this time. If access to the Resources attribute become available at some later time we can revisit then.

[debu99]

How to output this security group id only by terraform?

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!