The Secret Life of AWS: The Principle of Least Privilege (IAM Roles & Policies)
Why AdministratorAccess is a security vulnerability, not a bug fix.
Part 40 of The Secret Life of AWS
Timothy stared at the console. His Lambda function, designed to upload user profile pictures to S3, was failing.
Error: AccessDenied: Access Denied
"I don't have time to debug permissions," Timothy muttered. "I just need the function to write to the bucket."
He navigated to the IAM (Identity and Access Management) console. He found the Execution Role for his Lambda function.
He clicked Attach Policy.
He searched for AdministratorAccess.
He clicked Attach.
He ran the code again.
Success. The image appeared in the bucket.
"Problem solved," Timothy said.
Margaret walked in. "I saw the alert. Did you just attach AdministratorAccess to a production Lambda function?"
"It was getting permission errors," Timothy explained. "I gave it admin rights so it wouldn't get blocked. I just wanted it to work."
"Timothy," Margaret said, pulling up a chair. "You didn't fix the problem. You just removed the safety mechanism. In security architecture, 'making it work' is not the same as 'making it secure'."
"We need to discuss the Principle of Least Privilege."
The Identity (The Role & Trust Policy)
Margaret opened the IAM console and immediately detached the AdministratorAccess policy.
"Let's look at the architecture," she said. "Your Lambda function is an entity—a Principal. To interact with AWS services, it must assume an IAM Role."
"Think of the Role as the function's identity badge. But who is allowed to wear this badge?"
She clicked on the Trust Relationships tab.
"This is the Trust Policy," she explained. "It explicitly states that only the service lambda.amazonaws.com can assume this role. Even if I (a user) wanted to wear this badge to hack the system, the Trust Policy would reject me. We must lock down who can use the keys before we decide what the keys can open."
The Permission (The Policy)
"Now, we define exactly what this function is allowed to do," Margaret said. "We do that with an IAM Policy."
"When you attached AdministratorAccess," she continued, "you allowed this function to delete databases, terminate EC2 instances, and wipe backups. If an attacker injects code into your function, they become an Administrator."
She clicked Create Policy.
"We are going to craft a Customer Managed Policy that grants only the specific actions required."
She opened the JSON editor.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::timothy-profile-pictures/uploads/*"
}
]
}
She broke down the syntax:
Effect: Allow.
This statement grants permission.
Action: s3:PutObject.
"This allows writing a file," Margaret said. "It does not allow GetObject (Reading) or DeleteObject (Deleting). Even if the function is compromised, it cannot steal data."
Resource: timothy-profile-pictures/uploads/*.
"We are scoping this to a specific folder," she emphasized. "It cannot touch the root of the bucket, and it certainly cannot touch any other bucket in the account."
The Verification (The Simulator)
"Before we attach this," Margaret said, "We verify it."
She opened the IAM Policy Simulator.
She selected the Role and the new Policy.
She simulated an action: s3:DeleteObject.
Result: Denied.
She simulated: s3:PutObject on the uploads/ folder.
Result: Allowed.
"Now we know it works," she said, "and we know it fails correctly."
The Blast Radius
Margaret attached the new, scoped policy to the Lambda Role.
Timothy ran the code. Success. The image uploaded.
"Functionally, it is identical," Margaret said. "But architecturally, the risk profile is completely different."
"We have minimized the Blast Radius," she explained. "If this function is compromised now, the attacker is trapped. They can upload files to one specific folder. They cannot read data, they cannot delete infrastructure, and they cannot pivot to other services."
Timothy looked at the JSON policy. "It's more work to write this out than to just click 'Admin'."
"Security is always more work upfront," Margaret agreed. "But AdministratorAccess is technical debt. Every time you use it, you are borrowing time against a future breach."
Key Concepts
- IAM Role: An identity with specific permissions that is assumable by a service (like Lambda). It does not have long-term credentials.
- Trust Policy: A JSON document attached to a Role that defines who (which Principal) is allowed to assume that Role.
- IAM Policy: A JSON document that defines what permissions the Role has.
- IAM Policy Simulator: A tool to test and troubleshoot IAM policies to verify permissions before deploying them.
- Principle of Least Privilege: The security best practice of granting only the permissions necessary to perform a task, and no more.
- Blast Radius: The potential impact of a security breach. Scoping permissions reduces the blast radius.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment