An EC2 instance role is set to `*:*` (full admin) 'to make things work.' Why is this dangerous and what do you do?
Short answer
An over-privileged instance role turns any application-level flaw — notably an SSRF that reaches the instance metadata service — into full-account takeover, because the attacker inherits the role's credentials. Replace the wildcard with the minimal actions and resource ARNs the workload actually uses, and require IMDSv2 to harden the metadata endpoint. A VPC doesn't constrain IAM at all. A single deny rule is whack-a-mole that leaves everything else permitted. A load balancer is irrelevant to the credential's blast radius.
This scenario probes whether a senior engineer understands blast radius: the question isn't whether the instance is reachable, it's what an attacker gets the moment they get any foothold. A *:* role means a single bug is the whole account.
Why least privilege is the answer
An instance role's credentials are available to anything running on (or able to coerce) the instance. The classic path is SSRF: an application that can be tricked into making a request to http://169.254.169.254/... will hand back the role's temporary credentials. If the role is admin, the attacker now controls the entire account — they can read every bucket, create users, disable logging, and pivot. Scoping the role to the specific actions and resource ARNs the workload uses means even a perfect SSRF yields only what that one workload could already do. Requiring IMDSv2 (token-based, with a hop limit) makes the metadata endpoint far harder to reach via SSRF in the first place.
Why the distractors fail
- "Fine as long as it's in a VPC." A VPC is network isolation; it does not constrain IAM. The stolen credentials work against AWS's public API endpoints regardless of where the instance sits.
- Add one deny rule. Deny-listing a single risky action leaves thousands of other privileged actions allowed. Least privilege is an allow-list, not a game of whack-a-mole.
- Put it behind a load balancer. A load balancer changes how traffic reaches the app; it does nothing about what the leaked credential can do.
What interviewers look for
Naming SSRF + the metadata service as the realistic exploit path, insisting on allow-listed least privilege rather than deny patches, and adding IMDSv2 as defense in depth. A senior candidate also mentions how to derive the minimal policy safely — for example, running in a non-prod account with IAM Access Analyzer or CloudTrail-driven policy generation before tightening.
Likely follow-ups
- How exactly does SSRF against the metadata service exfiltrate role credentials, and how does IMDSv2 break that chain?
- How would you derive the minimal policy without breaking the workload?
- What's the blast radius difference between an over-privileged role and an over-privileged user?