The deploy role that can do anything

Lab machine

A private Linux machine with the problem already set up. Sessions last up to 60 minutes.

Priya Raman opened SEC-322 at 11:00SEV-2

The access review found that the CI role every Waybill deploy assumes can do far more than deploy Waybill. Its policy was "temporary, for the migration", and then "narrowed" once. Nobody has compared it with what the pipeline calls.

Every Waybill deploy assumes role/waybill-deploy through the CI's identity provider. Anyone who gets a workflow merged to main gets that role.

"It was temporary, for the migration. We narrowed it later, I think." (Sasha)

"What does the pipeline actually call? Give it that and nothing else." (Priya)

The lab runs an offline simulated AWS account. The aws CLI in your terminal is already pointed at it.

Your task

Replace the role's permissions with exactly what the deploy job needs: the actions it calls, on the resources it touches. Leave the trust policy alone.

On the machine

pipeline/deploy.yml: every AWS call the deploy job makes
aws iam list-role-policies --role-name waybill-deploy, aws iam get-role-policy ...
policies/waybill-deploy.json, policies/trust.json

Timeline

2026-03-12Sasha gives the deploy role "*" for the registry migration.

10:30The quarterly access review flags role/waybill-deploy.

10:50"What does the pipeline actually call? Give it that and nothing else." (Priya)

11:00SEC-322 lands with you.

Done when

The deploy job can still make every call in pipeline/deploy.yml.
The role can do nothing else, including other repositories, other bucket paths, other services, and IAM.
The role's trust policy is unchanged.

How it is checked:The checker compares the trust policy with the one created at setup, then evaluates every policy on the role (inline and attached). It requires the 10 calls the deploy job makes to be allowed and 12 calls it never makes, from creating IAM users to redeploying Ledger, to be refused. Statements with a Condition are not evaluated.

Passed. Here is how others fixed it

This lab has 2 versions. Reset for a fresh machine, and you may get a different one.

Break it for a friend. Pick the version they get, and the link is copied for you to send: version 1 · version 2

Other fixes that also pass:

Put the same statements in a customer-managed policy, attach it to the role, and delete the inline policy.

Fixes that look right but are not:

Narrowing to service wildcards such as `s3:*` and `ecr:*`, which still allow deleting buckets and repositories.
Scoping ecr:GetAuthorizationToken to the repository; it only works with "*".
Editing the trust policy instead of the permission policy.

Why it broke. The trust policy decides who can become the role, and it was right. The CI can assume it only for `main` of the waybill repository. The permission policy decides what the role can do once assumed, and "*" on "*" made every merged workflow an account administrator. Listing the exact calls turns a compromised pipeline from "anything in production" into "push a Waybill image and roll Waybill".

How Mara worked it

Read every comment in pipeline/deploy.yml
The pipeline lists each AWS call and the resource it touches.
Write one statement per step, with exact actions and ARNs
Turn the list into a policy, one job per statement.
Keep ecr:GetAuthorizationToken alone with Resource "*"
It has no resource to scope to; keep the wildcard to that one action.
aws iam put-role-policy --role-name waybill-deploy --policy-name deploy --policy-document file://...
The same name replaces the old wildcard policy.
aws iam get-role-policy --role-name waybill-deploy --policy-name deploy
Read back what is attached, and check nothing else is attached to the role.

Hints

Hint 1

Start from the comments in `pipeline/deploy.yml`. They list each action and the resource it acts on.

Hint 2

One action in the list has no resource to scope to. That one needs `"Resource": "*"`.

Hint 3

`ecr:*` on `*` is still a wildcard: it can delete every repository. And `iam:PassRole` on any role lets the pipeline hand itself an admin role.

Hint 4

Replace the inline policy with `aws iam put-role-policy`; the same name overwrites it.

Show the solution

Read the attached policy (`aws iam get-role-policy --role-name waybill-deploy --policy-name deploy`): `"*"` on everything, or whole services (`ecr:*`, `s3:*`, `ecs:*`) on every resource plus `iam:PassRole` on any role. Replace it with four statements from the comments in `pipeline/deploy.yml`: ecr:GetAuthorizationToken on "*", the six push actions on `arn:aws:ecr:eu-central-1:123456789012:repository/waybill`, s3:PutObject on `arn:aws:s3:::northstar-releases/waybill/*`, and ecs:UpdateService plus ecs:DescribeServices on `arn:aws:ecs:eu-central-1:123456789012:service/depot-cluster/waybill`. Apply it with `aws iam put-role-policy --role-name waybill-deploy --policy-name deploy --policy-document file://...`. The pipeline passes no role, so it needs no iam:PassRole.

Cloud Access

Identities, roles, and least privilege

A role's trust policy says who can become it; its permission policies say what it can do. Build permissions from the calls a job makes.

Two questions, two policies

Every role answers two separate questions. Who can become this role? That is the trust policy. For a CI deploy role it usually names the CI's identity provider and narrows it with a condition, for example only workflows from main of one repository. What can the role do once assumed? That is the set of permission policies, inline or attached. Mixing them up is common. A role with a tight trust policy and "Action": "*" is still an administrator for anyone who gets a workflow merged.

How a request is decided

A statement has an Effect (Allow or Deny), the Actions it covers (s3:PutObject, ecr:*), the Resources it applies to as ARNs, and sometimes a Condition. AWS starts from deny. A request is allowed only if some applicable statement allows it and none denies it. An explicit Deny always wins. Wildcards match more than they seem to: s3:* includes DeleteBucket, and a Resource of * includes every bucket in the account, including the ones holding customer data.

Least privilege from evidence

Write a role's policy from the job, not from what makes the error go away. List every API call the job makes and the resource each one touches. A deploy pipeline might log in to the registry, push one repository, upload under one bucket prefix, and update one service. Each line becomes a statement. A few actions, such as ecr:GetAuthorizationToken, have no resource to scope to and need "Resource": "*". Keep those statements to the single action. Then check both directions: the job's calls succeed, and the things it never does, such as touching another team's service, deleting repositories, or changing IAM, are refused. Policy simulators and access logs help, but the list in the pipeline file is the best evidence you have.

Temporary broad permissions have a way of becoming permanent. Give every exception an owner and an end date, and review roles that CI or automation can assume first. They are the ones an attacker reaches through your build system.

Key terms

Principal: The identity making a request, such as a user, a role session, or a service.
Trust policy: The resource policy on a role that says which principals may assume it.
Permission policy: A policy attached to an identity that lists what it may do on which resources.
Explicit deny: A Deny statement that matches a request. It overrides any Allow.

Read further

AWS Identity and Access Management User Guide, Roles section, "Roles terms and concepts" (trust policy versus permissions policy) (Free online)
Who may assume a role, and how temporary credentials are issued, for example to a CI system through OIDC.
AWS Identity and Access Management User Guide, Reference, "Policy evaluation logic" (Free online)
Default deny, explicit allow, explicit deny, and how identity and resource policies combine within one account.
AWS Identity and Access Management User Guide, "Security best practices in IAM" (Free online)
Least privilege, refining permissions from access activity, and why wildcards in production roles are a risk.

The deploy role that can do anything SEC-322