-
Notifications
You must be signed in to change notification settings - Fork 19
Description
User Story
As a user deploying Sleeper, I want to avoid use of the default security group, so that Sleeper's deployed resources have correct, minimal network access settings.
Description / Background
Under epic:
By default Sleeper's ECS tasks are deployed in the default security group for the VPC. If you don't want that, currently you need to set the instance property sleeper.ecs.security.groups.
This is not ideal as these components are internal to Sleeper, and do not communicate externally. Sleeper can be fully responsible for configuring networking for these components.
This setup may also behave in unexpected ways when we add long running ECS services, e.g. for queries. The networking needs for this will be different to other components running in ECS, so we probably don't want to put them all on the same security groups.
We'd like to create security groups for ECS tasks deployed in Sleeper as part of the Sleeper CDK deployment, so that we can configure the network access needed.
Technical Notes / Implementation Details
We could adjust the instance property sleeper.ecs.security.groups, to clarify this is for ECS tasks that are internal to Sleeper.
The security group that an ECS task runs in is currently chosen when the lambda starts a task, in the API call to ECS. This reads an instance property for whether to use the default security group, or specified security groups.
The CDK has a construct SecurityGroup, which we currently use for the build EC2. We could set CDK-defined instance properties for one or more of these, which we could reference when we start an ECS task.
Needed configuration for existing ECS tasks
A security group configures which network traffic will be allowed into and out of the resource.
The current ECS tasks in the system do not run a web server, so will not need to allow any incoming traffic.
They do make outgoing requests to AWS APIs. We may not need to restrict this much at the level of the security group.
For now it only seems important to create the security groups ourselves. If we wanted to restrict the outbound traffic we can leave that for the future.