aws / aws/aws-cdk

(aws-ecs): FargateService adds In- and EgressRules for all SecurityGroups

Open
#18,245 19 comments 10 reactions 0 assignees View on GitHub
@aws-cdk/aws-ecs bug effort/medium p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
1d 19h
Merged PRs (30d)
74

Description

### What is the problem?

When configuring a FargateService with multiple SecurityGroups additional Egress Rule changes (e.g. for Load Balancer to Target) are created for all of them. This applies even for external SGs that are imported by `fromSecurityGroupId()` and have set `{mutable: false}`.

### Reproduction Steps

I created a minimal example in this github [repository](https://github.com/bedaka/aws-cdk-fargate-securitygroup-example)
```javascript
const externalDbSg = SecurityGroup.fromSecurityGroupId(
this,
"ExternalDbSg",
Fn.importValue("external-database-sg"),
{ mutable: false, allowAllOutbound: true }
);

const fargateSG = new SecurityGroup(this, "FargateSg", {
vpc,
});

const targetGroup = new ApplicationTargetGroup(this, "TargetGroup", {
vpc,
port: 8080,
});

new ApplicationLoadBalancer(this, "Alb", {
vpc,
internetFacing: true,
}).addListener("Listener", {
port: 443,
certificates: [ListenerCertificate.fromArn("arn")],
defaultAction: ListenerAction.forward([targetGroup]),
});

const task = new TaskDefinition(this, "Task", {
compatibility: Compatibility.FARGATE,
cpu: "512",
memoryMiB: "1024",
});

task.addContainer("Image", {
image: ContainerImage.fromRegistry("amazon/amazon-ecs-sample"),
portMappings: [{ containerPort: 8080 }],
});

const service = new FargateService(this, "FargateService", {
cluster: cluster,
taskDefinition: task,
securityGroups: [fargateSG, externalDbSg],
});

service.attachToApplicationTargetGroup(targetGroup);
```
### What did you expect to happen?

The Rules are only created for the SG I created for the FargateService (and is mutable).

I'm migrating the service from Cloudformation to CDK and before there was no issue attaching multiple SGs a FargateService. I understand that now where the L2 Construct is creating the Rule for Traffic from the LoadBalancer itself and has no real way of "knowing which SG belongs to the service". But there should be a way (that I might be missing) of implementing this so that not every Egress rule is created multiple times.

### What actually happened?

For every SG assigned to the FargateService Egress rules are created for the Resources that have a connection to the service. In my provided example this is only the Load Balancer but this applies for all connections added to the service. While a single additional Egress rule is not that much of an issue, this can become quite irritating when working with multiple services that have access to multiple Resources.

### -- EDIT --
I made some pictures to make the situation clear
- ExternalSg imported with `mutable: true`
![SG_mutable_true](https://user-images.githubusercontent.com/33041245/149154024-8217d937-bc1e-4020-b623-37b3dc5ce4fb.png)
- ExternalSg imported with `mutable:false`
![SgsMutableFalse drawio](https://user-images.githubusercontent.com/33041245/149154059-683c4464-8d63-4f60-8f64-4d1b9bb95218.png)
- Desired Outcome
![SgsDesired drawio](https://user-images.githubusercontent.com/33041245/149154097-eed51506-010d-42a6-81aa-dfd059251b21.png)

### CDK CLI Version

2.1.0

### Framework Version

2.1.0

### Node.js Version

14.17.3

### OS

Ubuntu 20.04

### Language

Typescript

### Language Version

3.9.7

### Other information

_No response_

Contributor guide

Open the contributing guide

Research direction

Start with the minimal reproduction repository and the FargateService configuration in the issue, then trace how SecurityGroup.fromSecurityGroupId() with mutable: false is handled when the service is attached to the ApplicationTargetGroup. Done means the generated rules match the desired outcome: connection rules are not added to the imported, immutable security group.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.