Normalizing AWS IAM Policies for use in automated analysis | Hacker News Reader

Normalizing AWS IAM Policies for use in automated analysis

steampipe.io

32 pointsdboeke7 comments

Reminds me of Lyft's thing from a couple of months ago: https://news.ycombinator.com/item?id=25000950

I would love to get answers to questions like "which users have access to resource X, including implicitly through one or more assume-role jumps, across these N accounts, including stuff like iam:PassRole, even including tag-based policies?". Add a time dimension too, like "who had access to X between Jun and Aug 2020?", and you'd have a winner. Would such queries be possible here?

I just glanced over the source, but I think the answer is no in both cases.

> "which users have access to resource X, including implicitly through one or more assume-role jumps, across these N accounts, including stuff like iam:PassRole, even including tag-based policies?"

This would be difficult to pull off because you'd need to make separate calls to each of your accounts to determine this sort of thing. And if you're looking at assuming roles through mulitple accounts, you have to consider whether external Ids are defined.

And if external Ids are defined, how do you handle that? Do you assume the caller has the external Id?

> "who had access to X between Jun and Aug 2020?"

This one would be easier, but would require integration with AWS Config.

The joins are very powerful. For example - you can connect a lambda function to its IAM role and then right through to the attached policies. We have quite a few join examples scattered through the AWS table docs. For tags, Steampipe actually normalizes a tags column across AWS, Azure, GCP & DigitalOcean tables. It's always available as a JSONB {"foo":"bar"} format, even if the source was labels like DigitalOcean, so definitely possible to find resources with specific tags. We have multi-account on the near-term roadmap, but the idea of historical searches is a super interesting and challenging idea… we haven’t started to contemplate yet. Perhaps using snapshots into a materialized view would work for comparisons over time?

Hey ... author here. Happy to answer any questions, and would love your feedback or suggestions!

Hey there. This looks interesting. It looks like you're enumerating IAM managed policies. How do you handle inline policies? That seems like it'd be a blindspot if you're just enumerating the policies the account.

We also return the inline policies for users, groups, and roles. There's an open issue to convert them to standard form that I expect will be done in the next week, so this will also be possible.

Thanks for sharing the source, I've also parsed IAM policies with Go and it requires some thought. Your solution is nicer to look at I think. I worked with a guy whose basic philosophy was whatever AWS recommends do the exact opposite and his IAM policies are rats nest of denies and nots. It is usually easier to rewrite them than debug them - looking to see if this might ease the burden.

Reply on news.ycombinator.com