AWS securityhub documentation change
Summary
Added three new ECS security controls: ECS.19 (managed termination protection for capacity providers), ECS.20 (non-root users for Linux containers), and ECS.21 (non-administrator users for Windows containers).
Security assessment
The change adds documentation for new preventive security controls addressing privilege escalation risks (ECS.20/ECS.21) and infrastructure protection (ECS.19). While these controls mitigate security risks like container escape attacks, the diff shows proactive best practices rather than fixes for specific disclosed vulnerabilities.
Diff
diff --git a/securityhub/latest/userguide/ecs-controls.md b/securityhub/latest/userguide/ecs-controls.md index f5136216c..795d8d71a 100644 --- a//securityhub/latest/userguide/ecs-controls.md +++ b//securityhub/latest/userguide/ecs-controls.md @@ -5 +5 @@ -[ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions[ECS.2] ECS services should not have public IP addresses assigned to them automatically[ECS.3] ECS task definitions should not share the host's process namespace[ECS.4] ECS containers should run as non-privileged[ECS.5] ECS containers should be limited to read-only access to root filesystems[ECS.8] Secrets should not be passed as container environment variables[ECS.9] ECS task definitions should have a logging configuration[ECS.10] ECS Fargate services should run on the latest Fargate platform version[ECS.12] ECS clusters should use Container Insights[ECS.13] ECS services should be tagged[ECS.14] ECS clusters should be tagged[ECS.15] ECS task definitions should be tagged[ECS.16] ECS task sets should not automatically assign public IP addresses[ECS.17] ECS task definitions should not use host network mode[ECS.18] ECS Task Definitions should use in-transit encryption for EFS volumes +[ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions[ECS.2] ECS services should not have public IP addresses assigned to them automatically[ECS.3] ECS task definitions should not share the host's process namespace[ECS.4] ECS containers should run as non-privileged[ECS.5] ECS containers should be limited to read-only access to root filesystems[ECS.8] Secrets should not be passed as container environment variables[ECS.9] ECS task definitions should have a logging configuration[ECS.10] ECS Fargate services should run on the latest Fargate platform version[ECS.12] ECS clusters should use Container Insights[ECS.13] ECS services should be tagged[ECS.14] ECS clusters should be tagged[ECS.15] ECS task definitions should be tagged[ECS.16] ECS task sets should not automatically assign public IP addresses[ECS.17] ECS task definitions should not use host network mode[ECS.18] ECS Task Definitions should use in-transit encryption for EFS volumes[ECS.19] ECS capacity providers should have managed termination protection enabled[ECS.20] ECS Task Definitions should configure non-root users in Linux container definitions[ECS.21] ECS Task Definitions should configure non-administrator users in Windows container definitions @@ -404,0 +405,78 @@ For information about enabling in-transit encryption for Amazon ECS Task Definit +## [ECS.19] ECS capacity providers should have managed termination protection enabled + +**Category:** Protect > Data Protection + +**Severity:** Medium + +**Resource type:** `AWS::ECS::CapacityProvider` + +**AWS Config rule:** `ecs-capacity-provider-termination-check` + +**Schedule type:** Change triggered + +**Parameters:** None + +This control checks whether an Amazon ECS capacity provider has managed termination protection enabled. The control fails if managed termination protection is not enabled on an ECS capacity provider. + +Amazon ECS capacity providers manage the scaling of infrastructure for tasks in your clusters. When you use EC2 instances for your capacity, you use Auto Scaling group to manage the EC2 instances. Managed termination protection allows cluster auto scaling to control which instances are terminated. When you used managed termination protection, Amazon ECS only terminates EC2 instances that don't have any running Amazon ECS tasks. + +###### Note + +When using managed termination protection, managed scaling must also be used otherwise managed termination protection doesn't work. + +### Remediation + +To enable managed termination protection for an Amazon ECS capacity provider, see [Updating managed termination protection for Amazon ECS capacity providers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-managed-termination-protection.html) in the _Amazon Elastic Container Service Developer Guide_. + +## [ECS.20] ECS Task Definitions should configure non-root users in Linux container definitions + +**Category:** Protect > Secure access management > Root user access restrictions + +**Severity:** Medium + +**Resource type:** `AWS::ECS::TaskDefinition` + +**AWS Config rule:** `ecs-task-definition-linux-user-non-root` + +**Schedule type:** Change triggered + +**Parameters:** None + +This control checks whether the latest active revision of an Amazon ECS task definition configures Linux containers to run as non-root users. The control fails if a default root user is configured or user configuration is absent for any container. + +When Linux containers run with root privileges, they pose several significant security risks. Root users have unrestricted access within the container. This elevated access increases the risk of container escape attacks, where an attacker could potentially break out of container isolation and access the underlying host system. If a container running as root is compromised, attackers may exploit this to access or modify host system resources, affecting other containers or the host itself. Furthermore, root access could enable privilege escalation attacks, allowing attackers to gain additional permissions beyond the container's intended scope. The user parameter in ECS task definitions can specify users in several formats, including username, user ID, username with group, or UID with group ID. It's important to be aware of these various formats when configuring task definitions to ensure no root access is inadvertently granted. Following the principle of least privilege, containers should run with the minimum required permissions using non-root users. This approach significantly reduces the potential attack surface and mitigates the impact of potential security breaches. + +###### Note + +This control only evaluates the container definitions in a task definition if the `operatingSystemFamily` is configured as `LINUX` or `operatingSystemFamily` is not configured in the task definition. The control will generate a `FAILED` finding for an evaluated task definition if any container definition in the task definition has `user` not configured or `user` configured as default root user. The default root users for `LINUX` containers are `"root"` and `"0"`. + +### Remediation + +For information about creating a new revision of an Amazon ECS Task Definition and updating the `user` parameter in the container definition, see [Updating an Amazon ECS task defintion](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the _Amazon Elastic Container Service Developer Guide_. + +## [ECS.21] ECS Task Definitions should configure non-administrator users in Windows container definitions + +**Category:** Protect > Secure access management > Root user access restrictions + +**Severity:** Medium + +**Resource type:** `AWS::ECS::TaskDefinition` + +**AWS Config rule:** `ecs-task-definition-windows-user-non-admin` + +**Schedule type:** Change triggered + +**Parameters:** None + +This control checks whether the latest active revision of an Amazon ECS task definition configures Windows containers to run as users that are not default administrators. The control fails if a default administrator is configured as user or user configuration is absent for any container. + +When Windows containers run with administrator privileges, they pose several significant security risks. Administrators have unrestricted access within the container. This elevated access increases the risk of container escape attacks, where an attacker could potentially break out of container isolation and access the underlying host system. + +###### Note + +This control only evaluates the container definitions in a task definition if the `operatingSystemFamily` is configured as `WINDOWS_SERVER` or `operatingSystemFamily` is not configured in the task definition. The control will generate a `FAILED` finding for an evaluated task definition if any container definition in the task definition has `user` not configured or `user` configured as default administrator for `WINDOWS_SERVER` containers which is `"containeradministrator"`. + +### Remediation + +For information about creating a new revision of an Amazon ECS Task Definition and updating the `user` parameter in the container definition, see [Updating an Amazon ECS task defintion](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the _Amazon Elastic Container Service Developer Guide_. +