Launch Week Day 3: Find overly permissive AWS IAM policies

Last week, I found myself staring at a mess of AWS IAM policies, trying to figure out why our new intern could assume a role that would allow them to accidentally terminate our production database. It wasn’t their fault – our IAM setup had grown into a labyrinth of permissions. If you’ve ever managed AWS at scale, you’re probably nodding along right now.

The visibility challenge with cloud permissions ​

AWS Identity and Access Management (IAM) is huge and complex. As your cloud infrastructure grows, so does the complexity of your IAM policies. Before you know it, you’re juggling hundreds of roles, thousands of policies, and millions of permutations of who can do what to which resource. It’s like playing 4D chess, except the pieces keep multiplying when you’re not looking.

The problem isn’t just complexity – it’s visibility. Traditional tools like AWS IAM Access Analyzer are useful, but they’re like trying to map the ocean floor with a flashlight. They show you bits and pieces, but never the whole picture. And let’s be honest, manually reviewing IAM policies is about as fun as watching paint dry, except the paint keeps changing color every time you blink.

This lack of clarity isn’t just annoying – it’s dangerous. Overly permissive policies can leave your infrastructure wide open to attacks. Overly restrictive ones can grind your operations to a halt. And in the murky middle, you’ve got a recipe for those “how did that happen?” moments that turn your hair gray.

Enter Access Edges. It’s a new feature we’ve been cooking up, and I’m genuinely excited about it. Imagine being able to see your entire IAM structure as a graph, where you can trace the path from any principal to any resource. Want to know everywhere your DevOps team has write access? Just a couple of clicks. Curious about who can potentially access that super-secret S3 bucket? Access Edges have got you covered.

In the next sections, we’ll dive deep into what Access Edges are, how they work their magic, and why they might just become your new best friend in the constant battle against IAM complexity. But first, let me grab another coffee – dealing with IAM permissions is thirsty work!

What are Access Edges? ​

Remember that scene in detective movies where they have a big board covered in photos, string, and sticky notes, trying to map out all the connections in a complex case? That’s essentially what Access Edges do for your AWS IAM setup, except it’s digital, dynamic, and a lot less likely to fall off the wall when someone sneezes.

At its core, Access Edges are a graph-based representation of your IAM permissions. But calling it just a “graph” is like calling the internet “a bunch of connected computers” - technically true, but missing the bigger picture.

Here’s how it works:

1. Nodes: These are the players in our IAM drama. On one side, you’ve got principals - users, roles, and groups. On the other, you’ve got AWS resources - EC2 instances, S3 buckets, Lambda functions, you name it. Each of these is a node in our graph.

2. IAM Edges: These are the connections between nodes, representing allowed actions. An IAM edge from a user to an S3 bucket might represent “s3:ListBuckets” access, while another could represent “s3:DeleteBucket” access.

3. Attributes: This is where it gets juicy. Each edge can have attributes that provide extra context. It could be the specific permissions granted, resource constraints, any conditions attached, or even which policy is granting this access.

Now, I know what you’re thinking: “Nikita, this sounds great, but how is this different from just looking at policy documents?” Well, imagine trying to understand the plot of Game of Thrones by reading each character’s diary separately. Sure, you’d get information, but you’d miss all the interactions and connections that make the story interesting (and occasionally traumatizing).

Access Edges take all those separate “diaries” (IAM policies) and weaves them into a coherent narrative. It’s not just about what’s in each policy, but how they all interact and overlap.

Here’s where it gets really powerful: traversal. While we don’t have a fancy interactive visual graph (yet - I’m hoping Santa’s elves are working on it), we do have a powerful graph search syntax. Want to find all the resources a particular role can touch? Easy. Curious about all the paths that lead to write access on your critical database? We’ve got you covered.

You can hop multiple edges, following the trail of permissions across your AWS account. It’s like playing Six Degrees of Kevin Bacon, except instead of finding out how a person is connected to Kevin Bacon, you’re discovering how your intern might accidentally have delete permissions on your production RDS instance. (Spoiler: It’s probably more than six degrees, and a lot less fun to discover.)

This approach turns IAM from a collection of static documents into a dynamic, explorable space. It’s the difference between having a pile of jigsaw puzzle pieces and seeing the completed picture. Except in this case, the picture is constantly changing, and some of the pieces might secretly be from other puzzles.

In the next section, we’ll dive into the key features of Access Edges and how you can use them to bring some sanity to your IAM setup. But for now, take a moment to imagine a world where you can actually understand your AWS permissions at a glance. Feels good, doesn’t it? Almost as good as finding that last matching sock in the laundry.

Benefits and use cases ​

Now that we’ve painted a picture of Access Edges as the Sherlock Holmes of your AWS permissions, let’s talk about why you’d want this digital detective on your team.

First off, let’s address the elephant in the room: IAM is complex, it’s finicky, and one wrong move can leave your entire AWS account exposed and vulnerable. Access Edges don’t make IAM a walk in the park, but they do make it significantly less daunting.

Visibility ​

Access Edges bring your entire IAM setup into clear view. Suddenly, permissions that were out of sight aren’t out of mind anymore. You can see the entire permission structure, including those sneaky hidden access paths that have been lurking in the shadows.

This visibility is like having x-ray vision for your AWS account. You can spot potential security risks before they turn into actual security incidents. It’s the difference between noticing a small crack in your ship’s hull and waiting until you’re recreating scenes from Titanic.

Auditing ​

If you’ve ever been through an audit, you know it’s about as enjoyable as counting grains of rice one by one. Access Edges turn this tedious process into something far more manageable.

With comprehensive permission mapping, you can easily track who has access to what resources. It’s like having a constantly updated guest list for the exclusive club that is your AWS environment. This makes compliance checks and reporting straightforward. Your auditors might actually finish early for once (though I wouldn’t bet the farm on it).

Proactive security ​

Access Edges don’t just show you your current IAM state; they help you build a proactive security posture. By identifying potential risks before they become issues, you’re essentially giving yourself a crystal ball for IAM-related problems.

This supports the principle of least privilege, which is just a fancy way of saying “don’t give people access to stuff they don’t need.” It’s like keeping the cookie jar on the top shelf – sure, most people probably won’t cause trouble, but why risk it?

Real-world use cases ​

Let’s put some faces to these benefits:

1. The security team: They’re using Access Edges to conduct regular access reviews. It’s like spring cleaning, but instead of finding forgotten items in the attic, they’re finding outdated permissions that should have been revoked months ago.

2. The DevOps squad: When an application starts throwing permission errors, they’re not playing whack-a-mole anymore. They can trace the exact permission path and find the blockage faster than you can say “who changed the IAM policy?”

3. The compliance officer: Our compliance hero is using Access Edges to prepare reports that actually make sense. It’s like translating a foreign language, but for IAM policies.

In essence, Access Edges are turning the murky waters of IAM into a crystal-clear pool. You might still find a few surprising creatures lurking in the depths, but at least now you can see them coming.

So, ready to dive in and start exploring your IAM universe? In the next section, we’ll look at how to get started with Access Edges. Spoiler alert: it’s easier than you might think, and you’re much less likely to end up with unexplainable loose ends.

Getting started with Access Edges ​

Let’s dive into the heart of Access Edges: the graph search syntax. This is where the magic happens, allowing you to traverse the complex web of IAM permissions with surgical precision.

The search syntax in Access Edges is powerful, flexible, and (once you get the hang of it) surprisingly intuitive. It’s based on the idea of traversing a graph, where nodes represent entities (like users or resources) and edges represent permissions.

Here’s a juicy example to sink our teeth into:

search is(aws_iam_user) and name == "matthias" -iam[0:]{can_become==true}-> is(aws_iam_user, aws_iam_role) -iam{write==true}->

Whoa, that’s a mouthful! But don’t worry, we’ll break it down step by step:

1. search is(aws_iam_user) and name == "matthias": This is our starting point. We’re looking for an IAM user named “matthias”.

2. -iam[0:]{can_become==true}->: This part is saying “follow any IAM access edges where the principal can become someone else by e.g. assuming a role”. The [0:] means “zero or more hops”, so it’ll find direct assumptions and chained ones too.

3. is(aws_iam_role): This ensures we’ve landed on an IAM role after our assume-role hop.

4. -iam{write==true}->: Finally, we’re looking for any resources that this role can write to.

Put it all together, and this query is asking: “Show me all the resources that Matthias can write to, either directly or by assuming one or more roles along the way.”

It’s like playing a game of connect-the-dots, but instead of a cute picture, you get a map of your AWS permissions. Fun, right?

Here’s a tip: start simple and build up. You could begin with just:

search is(aws_iam_user) and name == "matthias" -iam{write==true}->

This will give you all resources where “matthias” has write access to.

Then gradually add more complexity as you get comfortable with the syntax.

Remember, the power of this search lies in its ability to uncover indirect access paths. It’s not just about what Matthias can do directly, but what he could potentially do through a chain of role assumptions. This is the kind of insight that can make your security team jump for joy (or have a panic attack, depending on what you find).

Conclusion ​

So there you have it: Access Edges, the tool that turns your maze-like AWS IAM permissions into a neatly labeled map

The real power of Access Edges lies in their ability to show us the permissions we didn’t even know we had. It’s a bit like finding out your TV remote can also control your neighbor’s garage door - fascinating, but probably something you want to fix.

Access Edges aren’t just a fancy way to visualize your IAM mess. They’re a fundamental shift in how we approach cloud security. We’re moving from a world of static policy documents to one of dynamic permission paths. It’s the difference between reading about a maze and actually walking through it.

The implications are huge. Imagine being able to confidently say “no” when your auditor asks if there are any unexpected access paths to sensitive data. Picture your security team proactively closing off potential attack vectors before they become actual problems. Think about the peace of mind that comes from knowing exactly who can do what in your AWS environment.

Of course, the Access Edges feature isn’t a magic wand. It won’t write perfect IAM policies for you or make your coffee in the morning (though I’m lobbying hard for that feature in v2). What it will do is give you the insights you need to make informed decisions about your AWS security.

As cloud environments continue to grow in complexity, tools like Access Edges aren’t just nice to have - they’re becoming essential. It’s like trying to manage a modern city with medieval maps; at some point, you need to upgrade your tools.

So, what’s next? Well, I for one am excited to start exploring my AWS permissions in a way that doesn’t involve scrolling through endless JSON. I’m looking forward to uncovering those hidden access paths, tightening up our security, and maybe, just maybe, understanding our IAM setup well enough to explain it to someone else without breaking into a cold sweat.

Remember, in the world of security, knowledge truly is power. And with Access Edges, we’re not just powerful - we’re downright superhuman. Now if you’ll excuse me, I have some IAM policies to go and fix. Who knew our interns had write access to our production databases? Oh wait, Access Edges knew. And now, so do we.

Happy permission hunting, folks!