Industrial IAM Service Role Creation
Aug 27, 24
“Non-Human Identities” are super super hot right now.
So I’ve been thinking about how we create new IAM service roles in AWS.
There are two background factors to writing this post:
- I recently have been looking at the AWS IAM tool landscape, as part of publishing my updated AWS IAM Security Tooling Reference
- I’m an advisor to P0 Security, who are working on universal cloud access governance, which includes machine roles.
Traditionally, IAM roles are artisanally crafted by an IAM expert, who still will struggle because IAM roles are hard. I’m going to provide a survey of options and alternatives.
Methods
Domain Specific Language
One approach to simplifying the process is by introducing an intermediary tool. The most notable example is policy_sentry. The idea behind using a DSL is generally to allow users who are less familiar with IAM to explicitly reference attributes of access (like “read” or “write”), without needing to know each service’s idiosyncrasies. This is a core part of Noq IAMbiq (Noq has unfortunately shut down since).
GUI
We also see attempts to produce better UIs for crafting IAM permissions, which might be backed by JSON or a DSL, and might export policies, Cloudformation or Terraform. The most basic form would be the AWS Policy Generator. One is built into tools like ConsoleMe and many of the JIT cloud access vendors.
Natural language
The recent emergence of LLMs has led to tools that try to distill IAM from a natural language description of the necessary permissions. For example, there is an AWS IAM Policy Generator ChatGPT plugin. Slauth (YC22) tried to bring this to market as a product, unsuccessfully.
Defaults
When crafting policies, you have to choose whether you want to fail open or closed. To fail open, you knowingly risk over-provisioning roles initially, and later use access data to least privilege them. That approach can be served by AWS IAM Access Analyzer Policy Generation or Netflix’s Repokid. Failing safe involves creating granular policies up front, and using access errors to converge on least privilege. Access Undenied can help. Either way, ideally you’re improving your policies in a development or staging context, instead of doing so in production. The drawback is that restricting at the resource level can be difficult across environments.
Tools
Honestly, one of the coolest AWS tools I’ve ever seen. iamlive uses client-side monitoring (CSM) or its embedded proxy to generate an IAM policy based on the actual calls made by the AWS SDK. Adam Buggia at SymOps wrote up a guide to using iamlive with Localstack.
Also from Ian (how does he do it?!), iamfast tries to distill the necessary permissions from application code. This one is far more experimental!
AirIAM is designed to help you migrate from manual management into Terraform, while removing unused users, roles, groups, policies and policy attachments.
pike specifically targets Terraform, generating the minimum necessary IAM policy to run a successful apply.
Python chalice, similarly to iamfast, generates the necessary IAM policy directly from your application code.
iamzero was another Python-only swing at IAM policy generation. Instead of working off application code, it uses instrumentation to detect errors and automatically recommend least-privileged policies.