The Secret Life of AWS: The ID Badge (IAM Roles & Policies)

#aws#iam#devops#cloud

Why your Lambda function shouldn't have the keys to the kingdom. A guide to the Principle of Least Privilege.

Part 26 of The Secret Life of AWS

Timothy leaned back in his chair, feeling a deep sense of satisfaction.

"It is done, Margaret," he said. "The application is decoupled. It is observable. It is protected by a WAF. And the database password is locked in a rotating Vault."

"It is a fortress," he added with a grin.

Margaret smiled, appreciating his confidence. "It is certainly much stronger than it was a week ago. May I look at one last thing?"

"Of course."

Margaret navigated to the IAM (Identity and Access Management) console. She opened the Role attached to Timothy’s Checkout Lambda function.

She clicked on the Permissions tab.

{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

Margaret raised an eyebrow. "Timothy, this fortress... did you give the gatekeeper the Master Key to the entire kingdom?"

Timothy looked at the JSON policy. "I... well, when I was building it, I didn't know exactly what permissions I needed. So I gave it AdministratorAccess just to get it working. I meant to fix it later."

"It is the most common mistake in the cloud," Margaret said gently. "But think about it. You put a WAF on the front door to stop hackers. But if a hacker does find a way into your Lambda function, this policy gives them permission to delete your S3 buckets, shut down your databases, and even spin up Bitcoin miners in Virginia."

"Your function doesn't need to be a God with a Master Key," she said. "It just needs to be an employee with a specific ID Badge that only opens the doors it needs for its job."

The Wildcard (*)

"In AWS," Margaret explained, "the asterisk (*) is dangerous. It means 'Everything'. When you say Action: *, you are saying 'You can do anything you want'."

"But my function only needs to do three things," Timothy said, counting on his fingers.

1. Read the order from SQS.
2. Get the password from Secrets Manager.
3. Write the order to DynamoDB.

"Exactly," Margaret nodded. "So let's write a policy that does only those three things. This is called the Principle of Least Privilege."

The Badge

Margaret clicked Edit Policy. She deleted the Administrator access and started fresh.

"First, the Queue," she said.

{
    "Effect": "Allow",
    "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes"
    ],
    "Resource": "arn:aws:sqs:us-east-1:123456789012:OrdersQueue"
}

"Notice the Resource," she pointed out. "We aren't just saying 'You can use SQS'. We are saying 'You can use this specific queue'. If the function tries to touch the Shipping Queue, AWS will say 'Access Denied'."

"Next, the Vault," Timothy said, catching on.

{
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:ProductionDB-xxxx"
}

"Perfect," Margaret smiled. "It can open the safe, but it cannot delete the safe. It cannot create new secrets. It can only retrieve."

The Least Privilege

They finished the policy for DynamoDB. Timothy hit Save.

"It feels... restrictive," Timothy admitted. "Before, I didn't have to worry about permissions. Now, if I add a new feature, I have to update the ID Badge."

"That is true," Margaret agreed. "Security always adds a little friction. But think of the alternative."

"If someone compromises this function now," she continued, "what can they do? They can read an order. They can write an order. That is it. They cannot steal your data, delete your backups, or destroy your account."

"You have limited the Blast Radius," she said.

Timothy looked at the new policy. It was longer than the one-line * policy, but it told a story. It described exactly what the function was supposed to do—and nothing more.

"I used to think IAM was just annoying paperwork," Timothy reflected. "But it's actually part of the application design. It defines the boundaries."

"Precisely," Margaret beamed. "You are not just writing Python anymore, Timothy. You are defining the Identity of your infrastructure."

With the security foundation in place, Timothy's system was secure. Now, he could think about scaling it to the world.

---

Key Concepts

• IAM (Identity and Access Management): The service that controls "who" can do "what" in AWS.
• Roles vs. Users: Users are for humans (long-term passwords); Roles are for machines (temporary, secure credentials that rotate automatically).
• The Wildcard (*): The dangerous symbol that grants broad, unchecked access.
• Principle of Least Privilege: Granting only the specific permissions required to perform a task, and nothing more.
• Blast Radius: The amount of damage an attacker can do if they compromise a single component.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.