The Secret Life of AWS: IAM
.jpeg)
The Secret Life of AWS: IAM
Users, roles, and the policies that bind them
#AWS #CloudComputing #IAM
Margaret is a senior software engineer. Timothy is her junior colleague. They meet in a grand Victorian library in London — and in every episode, they work through the tools, ideas, and infrastructure that power modern software. Today, Timothy meets IAM — the most important service in AWS, and the most misunderstood.
Episode 5
Timothy arrived with the expression of a man who had been stopped at a door he expected to open.
He sat down, pulled out his notebook, and looked at Margaret with the particular frustration of someone who had done everything right and still been told no.
"Permissions," he said.
Margaret looked up from her book. "Tell me."
"I was following along at home. Trying to use the CLI — as instructed. I wanted to list the contents of an S3 bucket I had created." He set his pen down with more precision than the situation required. "Access denied."
"What did you do?"
"I spent forty minutes trying to understand why. I had created the bucket. It was my account. I was logged in." He paused. "And then I found a forum post that said — just give your user admin access and move on."
"And did you?"
"Yes," he said. "It worked immediately. And I felt vaguely as though I had done something I shouldn't have."
"You had," Margaret said pleasantly. "But the instinct that told you so is the one we're here to develop today."
The Lock Before the Key
"Before we talk about what you did," Margaret said, "I want to establish why IAM exists at all. Because it is tempting to experience it purely as an obstacle — the thing that stops you from doing what you want to do — and that framing will make you a worse engineer."
"It did feel like an obstacle."
"Most security feels like an obstacle until you understand what it is securing against." She folded her hands. "Imagine you are the owner of a large building. Many people work in this building — engineers, accountants, managers, contractors. Each of them has legitimate reasons to be there." She paused. "Do you give every person who works in the building a master key?"
"No," Timothy said. "Obviously not."
"Why not?"
"Because not everyone needs access to everything. The accountants don't need to be in the server room. The contractors don't need access to the executive floor." He paused. "And if someone loses their key, or leaves the company, or — is not who they claimed to be —"
"The blast radius," Margaret said, "is proportional to the access they had." She looked at him steadily. "Your AWS account is the building. IAM is the key system. Every user, every application, every service that interacts with your AWS resources needs a key — and that key should open exactly the doors it needs to open. No more."
"And the building has one more thing," she added. "A root key. The master of masters — the account root user, created when you first sign up for AWS. It can do everything, override everything, and cannot be fully restricted." She paused. "You should use it exactly once — to set up your account — and then put it away. Never use it for daily tasks. Never attach it to an application. Treat it the way you would treat a master key that, if lost, unlocks every door in every building you will ever own."
Timothy wrote that down without being asked.
"Least privilege," he said.
"Least privilege. The principle that every identity in your system should have the minimum access required to do its job. Not convenient access. Not generous access. Minimum access." She paused. "It sounds restrictive. It is, in fact, protective."
Three Concepts That Hold Everything Together
"IAM has three building blocks," Margaret said. "Once you understand them clearly, everything else follows."
Timothy opened his notebook.
"Users. Roles. Policies." She held up a finger for each. "They are distinct things that people frequently confuse, and the confusion causes most of the mistakes."
"Start with users."
"A user is an identity that represents a person. You — logging into your AWS account, running CLI commands, navigating the Console. A user has credentials — a username and password for the Console, or access keys for the CLI. A user persists. It exists until you delete it." She paused. "Users are for humans."
"And roles?"
"A role is an identity that represents a function, not a person. It has no permanent credentials. Instead, it is assumed temporarily — by a service, by an application, by a piece of code that needs to do something in AWS." She looked at him. "When your Lambda function needs to read from S3 — it does not log in with a username and password. It assumes a role. The role grants it the specific permissions it needs, for the duration of that operation, and no longer." She paused. "The role also has a trust policy — a separate document that defines who, or which service, is allowed to assume it. The Lambda function can assume the role because the trust policy explicitly permits it. Nothing assumes a role by accident."
"So roles are for machines."
"Roles are for anything that is not a human sitting at a keyboard. EC2 instances, Lambda functions, containers, external services that need to interact with your account — all of them should use roles, never user credentials." She paused. "This is one of the most commonly violated principles in AWS. Developers embed user access keys in application code — because it works, because it is easy, because they are in a hurry. And then the code ends up in a public repository, and the keys are discovered, and the account is compromised within minutes."
Timothy stopped writing. "Minutes?"
"There are automated scanners that watch public repositories continuously, looking for AWS access keys. The interval between a key appearing in a public commit and it being discovered and exploited is measured in minutes. Sometimes less." She looked at him calmly. "This is not a theoretical risk. It happens regularly, to experienced developers who knew better and were in a hurry."
"And roles prevent that because —"
"Because a role has no static credentials to steal. It generates temporary credentials at the moment of assumption, valid for a limited time, useless after they expire." She nodded once. "No key in the code. Nothing to find in the repository."
Policies — The Language of Permission
"The third building block," Margaret said, "is the policy. And this is where IAM becomes precise."
"A policy is a document," Timothy said. He had read ahead again.
"A policy is a JSON document that describes what is allowed and what is denied. It attaches to a user or a role and defines exactly what that identity can do. Each statement in the policy has three parts — the effect, which is allow or deny; the action, which is the specific AWS operation; and the resource, which is the specific thing the action applies to." She looked at him. "A policy might say — this identity can list S3 buckets, and read objects from this specific bucket, and nothing else. Not write. Not delete. Not access any other bucket. Exactly that, and no more."
"That's quite granular."
"That is the point. AWS permissions are not on or off — they are a precise specification. Which service, which action within that service, which specific resource the action applies to." She looked at him. "When you gave yourself admin access this morning — you attached a policy called AdministratorAccess. It is a real policy that AWS provides. It says, in effect — this identity can do everything. Every action. Every service. Every resource."
"Which is why it worked immediately."
"Which is why it worked immediately. And which is why it is the wrong answer for almost every situation." She paused. "For your personal account, experimenting at home — it is a reasonable shortcut. You are the only user. The blast radius of a mistake is limited to your own account. In a team environment, in a production system, attached to an application — AdministratorAccess is not a policy. It is the absence of a policy. It is the master key given to everyone."
What Goes Wrong — And What It Costs
"Let me be specific about the failure modes," Margaret said. "Because they are not abstract."
Timothy turned to a fresh page.
"Before I list them," she said, "I want you to notice something. Everything we have discussed — users, roles, policies, least privilege — is foundation. It sits beneath your application. A bug in your code affects your code. A mistake in IAM affects everything your code can touch — and potentially everything in your account. IAM mistakes are among the most consequential you can make in AWS, not because they are dramatic, but because they are foundational." She looked at him steadily. "With that in mind."
Timothy nodded.
"The first is credential exposure. Access keys embedded in code, committed to repositories, shared in messages. We have covered this. The consequences range from unexpected bills — someone using your account to mine cryptocurrency — to complete data loss." She said it without drama, simply. "Both happen."
"The second is overly permissive roles. An application that needs to read from one S3 bucket is given access to all S3 buckets — because it was easier to write the policy that way, because nobody thought carefully about the scope. When that application is compromised, the attacker has access to every bucket in the account."
"The third," she said, "is the dormant user. Someone joins a team, is given AWS access, leaves the team six months later. The access is never revoked. The credentials sit there — valid, forgotten, a door that is still open to someone who no longer works in the building." She paused. "This applies specifically to IAM Users — which, as we have established, should be reserved for humans. For roles, the equivalent hazard is an overly broad trust policy that permits more services or accounts to assume the role than actually need to. The principle is the same: access that exists but is no longer needed is a liability, not a convenience." She looked at him. "IAM hygiene is not a one-time task. It is ongoing. Credentials rotate. Users are audited. Roles are reviewed. Access that is no longer needed is removed."
Timothy looked at his notes. "This is more consequential than I expected."
"Now you understand why," Margaret said simply.
The Right Way Into the Problem
"So what should I have done this morning?" Timothy asked. "Instead of AdministratorAccess."
"You should have asked a more precise question," Margaret said. "Not — how do I make this work — but — what exactly does this need to do, and what is the minimum permission that allows it." She looked at him. "You needed to list the contents of an S3 bucket you created. That is one action — s3:ListBucket — on one resource — that specific bucket. A policy granting exactly that would have solved your problem without granting you the ability to terminate every EC2 instance in your account, delete every database, or modify your own IAM permissions."
"That last one," Timothy said slowly. "Modifying your own IAM permissions."
"Is how privilege escalation works," Margaret said. "An identity with overly broad IAM permissions can grant itself — or something it controls — even broader permissions. The attacker who compromises an over-permissioned role does not stop at what the role was intended to do. They use it as a stepping stone." She paused. "Least privilege is not just about limiting what goes wrong accidentally. It is about limiting what an attacker can do deliberately."
Timothy sat with that for a long moment.
"The forum post said just give it admin access and move on," he said finally.
"Forum posts optimize for making the error go away," Margaret said. "They do not optimize for what happens six months later when something else goes wrong." She picked up her book. "The two goals are not always in conflict. But when they are — you need to know which one you are serving." She paused, and looked at him directly. "Next time you are tempted to reach for AdministratorAccess — pause. Ask yourself: what is the minimum this actually needs? The answer is almost always narrower than you think. And narrower is safer."
Before Next Time
He was at the door before he turned back.
"The access keys," he said. "The ones I configured for the CLI. Are they in a safe place?"
Margaret regarded him. "Where did you put them?"
"In a configuration file. On my laptop." He paused. "Which I have not committed to any repository."
"Then they are in a reasonable place for now," she said. "There are better places — credential managers, IAM Identity Center for teams. We will get there. The fact that you thought to ask the question is the beginning of the right instinct."
He nodded once and left.
She turned back to the library's quiet, thinking that the developers who asked that question unprompted — before something went wrong — were rarer than they should be. And that today, at least, there was one more of them.
Next episode: Regions and Availability Zones — your infrastructure doesn't live in "the cloud." It lives somewhere specific. Timothy discovers that where you put things matters — for speed, for cost, for compliance, and for what happens when a data center has a very bad day.
Aaron Rose is a software engineer and technology writer at tech-reader.blog.
Catch up on the latest explainer videos, podcasts, and industry discussions below.
Comments
Post a Comment