ECS Container Running In Privileged Mode
ecs-container-privileged
What this rule checks
Detects ECS task definitions with a container running in privileged mode, which can access the host and escalate a container compromise into host compromise.
How to fix it
- 1Remove Privileged: true from the container definition unless strictly required
- 2Grant only the specific Linux capabilities the workload needs via LinuxParameters
import * as ecs from 'aws-cdk-lib/aws-ecs';
new ecs.CfnTaskDefinition(this, 'Task', {
containerDefinitions: [
{
name: 'app',
image: 'public.ecr.aws/nginx/nginx:latest',
privileged: true,
},
],
});import * as ecs from 'aws-cdk-lib/aws-ecs';
new ecs.CfnTaskDefinition(this, 'Task', {
containerDefinitions: [
{
name: 'app',
image: 'public.ecr.aws/nginx/nginx:latest',
privileged: false,
},
],
});CDK Insights pinpoints the exact file and line in your CDK source for every finding, so you can jump straight to the fix.
Affected resource types
AWS::ECS::TaskDefinitionIntentional? Suppress this finding
Sometimes a flag is deliberate — a genuinely public endpoint, say. You can dismiss ecs-container-privileged and the reason is kept in the report, not silently hidden.
In .cdk-insights.json:
{
"ignoreRules": [
{ "id": "ecs-container-privileged", "reason": "Why this is intentional" }
]
}Or inline in your CDK code:
Validations.of(scope).acknowledge({
id: 'cdk-insights::ecs-container-privileged',
reason: 'Why this is intentional',
});Use the rule ID ecs-container-privileged shown above — not the CDK-* ID from SARIF / GitHub code scanning. To dismiss every finding on one construct instead, use ignorePaths. Suppression docs →
Catch this in your stack
$ npx cdk-insights scanCDK Insights runs this and 118+ other rules locally against your synthesised CDK app — free, no account, your code never leaves your machine.