Iamlive – Generate an IAM policy from AWS client-side monitoring
I&#x27;ve dabbled in dev ops in recent months and found that setting up AWS services is relatively straightforward. Although for anyone reading this, do yourself a favor right now and learn to automate the manual steps with something like Terraform or you&#x27;ll most likely never get anywhere in any reasonable amount of time.<p>I found IAM to be an anti-pattern. I grew up on the Mac in a sandboxed, single-user environment with no console. And I&#x27;ve always approached roles and permissions as something that should be backend-only. So for web hosting, it should be host-only and not exposed to the customer.<p>So to me, a service like VPC should have created a sandbox that handles IAM internally. It should have provided the customer with all AWS services exposed (even oddballs like SES) in that sandbox only (not accessible from outside) similarly to how managed hosting worked a decade ago.<p>Basically IAM feels like hand waving to me. Few insights can be gleaned by looking at the roles and permissions by eye. So I would argue that most AIM setups as they stand now are probably insecure.<p>The way it should probably work is, the customer would set up a series of access tests that run similarly to Postman and exercise the infrastructure the way that something like Dredd does with Swagger or API Blueprint. They would &quot;prove&quot; the permissions ruleset by traversing the AWS infrastructure, telling you which ones to add&#x2F;remove.<p>So conceptually, I think that the article or something similar is how IAM should have worked in the first place. Thought I&#x27;d use this opportunity to ask any dev ops people about this, because it feels like I&#x27;m missing something fundamental here. Any approaches to formally proving that IAM roles and permissions are secure would be greatly appreciated!