Skip to content

Which role would you change when a container cannot read a secret?

1 min read · main part only; folded sections are optional

After this you can answer: Which role would you change when a container cannot read a secret?

A stopped task naming Secrets Manager during initialization points to the task definition’s secret reference, execution-role permission and network access. An application log naming an AWS SDK denial points to the credentials used by that process. The error’s caller ARN is stronger evidence than the name of a policy file.

The execution role also supports image pulls and container logging; it does not stop mattering after startup. The task role supports API runtime actions including SNS publishing, ticket reads, scoped object operations and ECS Exec channels.

This separation limits runtime IAM authority, but it does not hide injected secret values from application code. The app needs the database password to connect and can read its environment. A compromised application can therefore expose that password even without permission to call Secrets Manager. AWS documents the agent’s execution role; diagnose the actual operation before granting more authority.

Would adding secret permission to the task role fix startup injection?
No. ECS performs that read using the execution role; the application has not started yet.
What does a trust policy control?
Who can assume the role. The role permission policy controls which operations the resulting credentials can perform.
Why not use one large role?
It obscures which caller needs each action and gives runtime code unnecessary authority. Separate roles make failures and security reviews more precise.

Read the path chapter, select the relevant map piece →, then inspect infra/src/compute/iam.ts → createIamRoles. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/