I85PREP
⌘ K
AWS DevOps Engineer Professional study materials
AWS DevOps Engineer Professional study resources

Cross-Account Pipeline That Can Read Secrets It Should Not

AWS DevOps Engineer Professional · Put your knowledge to work in context.

All case studies

Cross-Account Pipeline That Can Read Secrets It Should Not

A build account runs CodeBuild projects that deploy into 12 workload accounts via assumed roles. A security review finds: (1) one CodeBuild service role has secretsmanager:GetSecretValue on * because a developer widened it to "make the build work"; (2) build logs print environment variables, including a database password injected as a plaintext env var; (3) the deploy roles in workload accounts trust the build account's root, not a specific role; (4) an engineer can edit the pipeline in the console and point it at a different source repo. The team wants least privilege but is afraid of breaking builds they don't fully understand.

1. Rank these four findings by risk and explain the blast radius of each.

Read the worked answer

Rough ranking by blast radius and exploitability:

  1. Deploy roles trusting the build account root (finding 3). Any principal in the build account - including a compromised or over-broad role - can assume deploy roles into all 12 accounts. This is the widest blast radius: full cross-account compromise. Trust should name a specific role ARN with an external ID/condition.
  2. GetSecretValue on * (finding 1). A compromised build (e.g., via a malicious dependency or PR) can read every secret in the account. High severity, and it's the classic "widened to make it work" debt.
  3. Plaintext secret in env vars logged (finding 2). The secret is now in logs, readable by anyone with log access, and persists per retention. Contained to one credential but requires rotation and log hygiene.
  4. Console pipeline edits (finding 4). Allows supply-chain redirection - point the pipeline at an attacker repo and deploy malicious code with the deploy roles. Serious, but requires console access in the build account; it compounds with #1/#3.

Note #4 combined with #3 is the worst path: redirect source, build malicious artifact, assume into all accounts.

2. Propose a remediation sequence that tightens these without a big-bang breakage, including how to handle the leaked credential and the fear of breaking builds.

Read the worked answer

Sequence to minimize breakage while closing the worst holes first:

  1. Rotate the leaked DB password immediately and purge/expire the logs that contain it. Treat it as compromised regardless of who could read it. Move secrets out of env vars: use Secrets Manager references resolved at runtime, or CodeBuild's native secret env support that isn't echoed, and add log masking.
  2. Fix the trust policies next (highest blast radius, low breakage risk): change workload deploy roles to trust the specific CodeBuild/pipeline role ARN with conditions, not root. Test with one workload account, then roll out.
  3. Scope the secret permission from * to the specific secret ARNs the build needs. To avoid breaking unknown builds, first enable CloudTrail data events / analyze access to see which secrets are actually read, scope to those, then iterate. Use AccessDenied alarms during rollout.
  4. Lock the pipeline definition to IaC with console edit disabled or change-controlled; require the source repo to be pinned and protected.

General approach: observe actual usage before narrowing, roll out per-account with a canary, and keep a short-lived, monitored exception path rather than leaving * in place.