undefined

points

[-]

I've implemented the AWS IAM engine and all policy types, conditions, etc in here if you want to try it out. It's the most thorough in terms of edge case coverage I'm aware of and I'm constantly adding enhancements and closing edge cases.

https://github.com/act-security-labs/iam-lens

It uses https://github.com/act-security-labs/iam-collect to get all the policies which includes example terraform to gather all the data at scale.

by donavanm13 hours ago|

prev|

[-]

The current IAM engine and language “balsa”, is its own thing. Its vended as a library with large “there be dragons” disclaimers if you even think about going outside the public interfaces. There are also big opaque interactions between different components like STS, KMS, service principals, service-specific resource policy evaluations, etc. I doubt that can be reasonably open sourced or exposed.

There was an attempt at a public implementation of the “next gen” AWS IAM language/engine with “cedar.” However I think that got sidetracked as an authz product and didnt have any real penetration with AWS IAM.

by solatic3 hours ago|

prev|

[-]

I shudder at the thought that local emulation is somehow supposed to handle IAM conditions like source VPC endpoints, EKS Pod Identity, chained roles originating from web identity providers...

IAM itself is free. Most IAM conditions involve resources which are free (e.g. VPC gateway endpoints, web identity providers) or which are free additions on top of a cluster you have for other purposes (e.g. EKS Pod Identity). Presumably you already have an AWS account. What value does an emulator give here?

by scriptsmith1 hours ago|

parent|

[-]

Yep, it's a complicated beast so I'd love to be able to mess around with it locally! I don't mind using an AWS account for a shared staging environment in the CI pipeline, but trying to figure out policies and roles during development, it can get a bit messy coordinating and handling the lifecycle of resources in a team's testing account (maybe this is easier if you get your own account?). And accounts aren't free when they require GuardDuty etc, unfortunately.

by solatic14 minutes ago|

parent|

[-]

> accounts aren't free when they require GuardDuty etc, unfortunately

This is probably the root of your problems. In principle, non-production accounts should have vastly reduced security requirements. Personally, I can't understand how companies are OK with offering more-or-less unrestricted guest WiFi (which, of course, has no access to production systems, let alone internal systems), but somehow offering minimally restricted AWS accounts (basically, just slap billing alarms on, maybe common-sense SCP-based restrictions like no public IPv4) for development purposes is problematic?

by Lucasoato13 hours ago|

prev|

[-]

I suppose it would have been extremely complex to replicate all of that. Maybe they thought it’s out of the scope to emulate all security patterns locally, they just wanted to focus into providing a native alternative to let users do integration tests.