[Question]: Adding an existing Security Group to an ALB

[robertd]

When I add an existing security group to elbv2.ApplicationLoadBalancer CFN still tries to create security group ingress resource. Is this by design? I thought that once you import the SG, ALB would just accept it as is (ISecurityGroup). Is this not the case or I’m doing something wrong? Do I need to use cfnLoadBalancer instead? Thanks!

 //Import existing VPC
    const vpc = ec2.VpcNetwork.importFromContext(this, "VPC", {
      vpcId: vpcId     
    });

    //Import existing Security Group
    const sg = ec2.SecurityGroup.import(this, "SecurityGroup", {
      securityGroupId: securityGroupId
    });

    //Create an instance of Elastic Load Blancer
    const alb = new elbv2.ApplicationLoadBalancer(this, "ALB", {
      vpc: vpc,
      securityGroup: sg,
      ipAddressType: elbv2.IpAddressType.Ipv4
    });

Resources:
  SecurityGroupfrom000004439CF506C4:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      IpProtocol: tcp
      CidrIp: 0.0.0.0/0
      Description: Allow from anyone on port 443
      FromPort: 443
      GroupId: sg-xxxxxxx
      ToPort: 443
    Metadata:
      aws:cdk:path: DlvEcsClustersStack/SecurityGroup/from 0.0.0.0_0:443
  ALBAEE750D2:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      IpAddressType: ipv4
      LoadBalancerAttributes: []
      Scheme: internal
      SecurityGroups:
        - sg-xxxxxxx
      Subnets:
        - subnet-xxxxxxxx
        - subnet-xxxxxxxx
        - subnet-xxxxxxxx
      Type: application
    Metadata:
      aws:cdk:path: DlvEcsClustersStack/ALB/Resource

[rix0rrr]

Ah, good point. It's actually not 100% obvious what the "correct" behaviour should be here, and I suspect reasonable people may have different reasonable opinions.

Right now, passing a SecurityGroup will prevent a new SecurityGroup from being created, but new rules will still be added to allow traffic back and forth between constructs.

This behavior is consistent with, for example, how Roles are passed in. We won't create a Role, but we will add new policy statements to the roles in order to make interactions between resources work.

The feature is currently intended more to allow sharing of objects such as SGs and Roles between constructs, rather than a complete abdication of management responsibilities by the CDK.

I imagine you're asking this from the perspective of someone who works at a company where the creation of "security-related" resources such as IAM roles and security groups is only allowed by a select group of non-application developers?

[Doug-AWS]

Rico, is this a sub-set of #1546 ?

[robertd]

@rix0rrr That is correct. We cannot create or update any IAM roles, policies or security groups.

[rix0rrr]

@Doug-AWS, no, don't worry about it.

[rix0rrr]

I think the correct solution for this problem is going to be:

• iam.ExternallyManagedRole, addToPolicy() will be a no-op.
• ec2.ExternallyManagedSecurityGroup, addIngressRule() and addEgressRule() will be no-ops.

[robertd]

@rix0rrr Thanks for helping me out with this, but I can't seem to find iam.ExternallyManagedRole or ec2.ExternallyManagedSecurityGroup to test it out. Is this currently supported in v0.25.1?

I can see addToPolicy(), addIngressRule() and addEgressRule() in my imported roles and SGs, but I'm not sure how to make them no-op. Can you please elaborate on no-op?

    //Import existing VPC
    const vpc = ec2.VpcNetwork.importFromContext(this, "VPC", {
      vpcId: props.vpcId    
    });

    //Import existing Security Group
    const sg = ec2.SecurityGroup.import(this, "SecurityGroup", {
      securityGroupId: props.securityGroupId
    });

    //Import existing taskRole
    const taskRole = iam.Role.import(this, "TaskRole", {
      roleArn: `arn:aws:iam::${props.accountId}:role/csr-Task-Role`
    });

    //Import existing executionRole
    const executionRole = iam.Role.import(this, "ExecutionRole", {
      roleArn: `arn:aws:iam::${props.accountId}:role/csr-Executor-Role`
    });

EDIT: I think I figured it out on no-op (see #1957), but I still need iam.ExternallyManagedRole & ec2.ExternallyManagedSecurityGroup clarification.

    sg.addIngressRule = () => {};
    sg.addEgressRule = () => {};
    taskRole.addToPolicy = () => {};
    executionRole.addToPolicy = () => {};

[robertd]

@rix0rrr Btw #1948 and #1957 are two separate stacks I'm working on but there is some topic overlap (i.e. cdk trying to perform changes on resources I have no control of - SGs, roles, policies, etc). Just wanted to clarify that. Thanks again for helping out. 👍

[rix0rrr]

You are right, the ExternallyManagedXxx classes I mentioned do not exist today.

You should be able to implement them yourself though.

class ExternallyManagedSomething extends cdk.Construct implements iam.IRole {
  public get roleArn(): string {
    return 'arn:aws:us-east-1:13245:role/my-role';
  }

  public addToPolicy(statement: iam.PolicyStatement) { 
    // do nothing
  } 
}

I've skipped over some details here so this code will not suffice for copy/pasting, but it should give you an idea on how to proceed.

[rix0rrr]

The unfortunate truth is we don't support your scenario as of today, so you're kind of on your own.

[robertd]

J/K... I'm going to give it a try and see if that prevents ingress/egress changes. Thanks again for helping me out.

[janaka]

I'm seeing the same behavior when creating a Fargate service and passing a ref to an existing SG, it seems to create a new one.

[ali-habibzadeh]

Same issue here. Any updates on this? Importing only creates new SGs and ignores the security group id passed into it

[prencher]

Similar issue, we have need of restricting a public LB to a security group's rules, but it forces creation of open-to-the-world port 80/443 rules in that group.

[okonon]

Also interested to hear about this

[alexanasteck]

Is there any progress on restricting public access on a load balancer with an already created security group? Not sure of a work around for this particular issue.

[rix0rrr]

SecurityGroup.fromSecurityGroupId now takes an "options" struct which allows making imported security groups immutable.

[kb-fusus]

Im having some what similar behavior
(we are using python cdk)

load_balancer_listener.add_target_groups(
                    id=f"{id_}-add-target-group-{i}",
                    **dict(target.target_add_props._values, target_groups=[target_group])
                )

this generates egress rule on load balancer's security group.

  commonpublicapplicationlistenerSecurityGroupsg:
    Type: AWS::EC2::SecurityGroupEgress
    Properties:
      Description: Load balancer to target
      DestinationSecurityGroupId:
        Fn::GetAtt:
          - SecurityGroupF181673F
          - GroupId
      FromPort: 8005
      GroupId: sg-0123456
      IpProtocol: tcp
      ToPort: 8005

So it seems like it took the port and protocol that I used to add Target Group and used it on it's default security group. (since I never imported this security group, I assume it automatically pulled default security group that was assigned to load balancer)

In my case, the biggest issue is that it replaces my egress rule that was allowing all traffic, causing other services in the load balancer to fail the healthcheck.
Could someone help me understand why it replaced the rule that was allowing all traffic egress rule?

The only way I found to avoid this rule is to manually fix cdk.conext.json where it pulls security group info
"allowAllOutbound" : false to "allowAllOutbound" : true but I couldn't find any cdk properties that I can set it in the code.

[MurraySpeight]

If using the ApplicationLoadBalancedFargateService construct then setting the boolean property openListener to false will prevent it adding the open 0.0.0.0/0 rule to the security group you pass in.