Skip to content
This repository has been archived by the owner on Nov 27, 2023. It is now read-only.

ECS: Compose adds ingress rule to security group when external #1783

Open
amrishparmar opened this issue Jun 11, 2021 · 4 comments
Open

ECS: Compose adds ingress rule to security group when external #1783

amrishparmar opened this issue Jun 11, 2021 · 4 comments
Labels
ecs enhancement ✨ A new feature suggestion or improvement upon an existing feature.

Comments

@amrishparmar
Copy link

amrishparmar commented Jun 11, 2021

Description

We are trying to set up a web service inside of a VPC, but we don't want to expose it to the public internet, so we set up a security group with the correct inbound/outbound rules. The problem is that the compose CLI (via the CF template it generates) modifies the existing security group to add 0.0.0.0/0 on port 80 thereby exposing the application to anyone.

Steps to reproduce the issue:

  1. Create a security group with a basic rule, e.g. HTTP, TCP, Port 80, 10.0.0.0/16
  2. Create a basic docker-compose config (which includes the relevant VPC and the security group created in previous step):
    x-aws-vpc: "vpc-123xyz789"
    
    services:
      web:
        image: nginxdemos/hello
        ports:
          - "80:80"
    
    network:
      default:
        external: true
        name: "sg-123abc456"
  3. Run docker compose up

Describe the results you received:

  • The application is running and accessible at the load balancer URL open to the internet.
  • The security group contains two rules: HTTP, TCP, Port 80, 10.0.0.0/16 and HTTP, TCP, Port 80, 0.0.0.0/0

Describe the results you expected:

  • The application is only accessible from HTTP calls made within the VPC
  • The security group is unchanged and only contains HTTP, TCP, Port 80, 10.0.0.0/16

Additional information you deem important (e.g. issue happens only occasionally):

The relevant section that creates the unwanted rule (show by docker compose convert) is the following

Default80Ingress:
  Properties:
    CidrIp: 0.0.0.0/0
    Description: web:80/tcp on default network
    FromPort: 80
    GroupId: sg-123abc456
    IpProtocol: TCP
    ToPort: 80

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: 1.0.17
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        f0df350
 Built:             Wed Jun  2 12:00:45 2021
 OS/Arch:           linux/amd64
 Context:           ecs-hosting-context
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       b0f5bc3
  Built:            Wed Jun  2 11:58:56 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker context show:
You can also run docker context inspect context-name to give us more details but don't forget to remove sensitive content.

ecs-hosting-context

Output of docker info:

(paste your output here)

Additional environment details (AWS ECS, Azure ACI, local, etc.):
AWS ECS

@ndeloof
Copy link
Collaborator

ndeloof commented Jun 14, 2021

A possible approach to address this request would be to leverage network attribute internal, so ECS integration knows network is not designed for connectivity from the Internet. Would then need to inspect the (existing) security group to guess the adequate CidrIp to be set.

@ndeloof ndeloof added ecs enhancement ✨ A new feature suggestion or improvement upon an existing feature. labels Jun 14, 2021
@jperuggia
Copy link

Ran into this issue as well, we are using a named security group which whitelists IP address that should have access to my application ( internal use case).

Example Docker Compose File:

x-aws-vpc: "vpc-0245e260761f4ecc4"
version: "3.9"
services:
  streamlit-app:
    image: 739988996933.dkr.ecr.us-east-1.amazonaws.com/aw-streamlitapp:v1
    ports:
      - target: 8501
        x-aws-protocol: http
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 2048M
    x-aws-policies:
      - "arn:aws:iam::aws:policy/AmazonSageMakerFullAccess"
networks:
  default:
    external: true
    name: sg-0ab458e44ca80883e

This also creates a section as mentioned above in the cloud formation template of :

Default8501Ingress:
    Properties:
      CidrIp: 0.0.0.0/0
      Description: streamlit-app:8501/ on default network
      FromPort: 8501
      GroupId: sg-0ab458e44ca80883e
      IpProtocol: "-1"
      ToPort: 8501
    Type: AWS::EC2::SecurityGroupIngress

Tried using the internal flag to true, when doing this and get an error of WARNING networks.internal: unsupported attribute Also tried to set external: false and neither produce the results desired.

We would like a way to not have the ingress of our security group modified if possible.

@blasto333
Copy link

I really need this

BackSlasher added a commit to BackSlasher/compose-cli that referenced this issue Jan 11, 2023
…the ingress rule to other security groups

Solves docker-archive#1783
Previously, the ECS stack included an ingress rule to allow LB to reach the tasks.
However, it added this ingress rule toe very Docker network security group, meaning other tasks on the same Docker network, possibly sensitive, were accessible externally.
We now create a new security group for port assignments for every service that has ports, and attach that security group only to that service.
This prevents other tasks in the same Docker networks are not accessible externally.
BackSlasher added a commit to BackSlasher/compose-cli that referenced this issue Jan 12, 2023
…the ingress rule to other security groups

Solves docker-archive#1783
Previously, the ECS stack included an ingress rule to allow LB to reach the tasks.
However, it added this ingress rule toe very Docker network security group, meaning other tasks on the same Docker network, possibly sensitive, were accessible externally.
We now create a new security group for port assignments for every service that has ports, and attach that security group only to that service.
This prevents other tasks in the same Docker networks are not accessible externally.
BackSlasher added a commit to BackSlasher/compose-cli that referenced this issue Jan 12, 2023
…the ingress rule to other security groups

Solves docker-archive#1783
Previously, the ECS stack included an ingress rule to allow LB to reach the tasks.
However, it added this ingress rule toe very Docker network security group, meaning other tasks on the same Docker network, possibly sensitive, were accessible externally.
We now create a new security group for port assignments for every service that has ports, and attach that security group only to that service.
This prevents other tasks in the same Docker networks are not accessible externally.

Signed-off-by: Nitzan Raz <[email protected]>
@BackSlasher
Copy link

Not sure how to add labels, but this is a security issue. I get random scrapes on my containers.
#security?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
ecs enhancement ✨ A new feature suggestion or improvement upon an existing feature.
Projects
None yet
Development

No branches or pull requests

5 participants