Iamlive sounds useful for someone who has something running with wide open permissions and wants to get started with narrowing down the permissions. It wastes a lot of time to discover necessary permissions one-by-one through permission-denied errors.<p>Tag-based policies (attribute based access control) really simplifies IAM policy management. These are more reusable, so there is permission discovery isn’t needed as often.
Google cloud got IAM right. I know of no approach to AWS IAM other than start with granting all perms and then begin to reduce privilege until things break.<p>AWS is untenable.
This is a analogous to the creation of a chroot jail (or, in more modern times a container) by observing a running app via pstrace and the like and noting which files it accesses. It’s a really powerful technique that can save a great deal of time for the programmer while ensuring the attack surface is as small as it can possibly be.<p>Back in the dark ages, I wrote a tool to create chroot jails in OpenBSD so as to minimize the size of a tar ball that would need to be distributed to run an app in an embedded system. Those days, flash storage was tiny and expensive, so not only was the jail technique more secure, it also saved money.
I'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'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'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 "prove" the permissions ruleset by traversing the AWS infrastructure, telling you which ones to add/remove.<p>So conceptually, I think that the article or something similar is how IAM should have worked in the first place. Thought I'd use this opportunity to ask any dev ops people about this, because it feels like I'm missing something fundamental here. Any approaches to formally proving that IAM roles and permissions are secure would be greatly appreciated!
I know there’s other projects with the goal to generate policies from the live behaviour of apps but I’ve always wondered how practical that actually is.<p>It seems difficult to make sure you actually exercise every path of your app so that it makes every API call.<p>It makes me wonder if live monitoring or static analysis is the better approach.
I think IAM is really, really cool. I’ve always wondered: is IAM a service under the hood? Surely not - the volume of requests would be insane and the single point of failure pretty risky.<p>So is it a spec with some kind of shared data plane to retrieve policies? If so how would they be evaluated consistently across different languages? Producing a shared library that does this in all contexts/languages sounds improbable. But then the policies are clearly compiled to some kind of bytecode, so a common implementation would make sense. But then again it is something that would definitely benefit from centralisation.
This can be done with more visibility using CloudWatch: <a href="https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring-cloudwatch.html" rel="nofollow">https://docs.aws.amazon.com/apigateway/latest/developerguide...</a>.<p>It’s not limited to API gateway or EC2.
It's mentioned in the readme, but CSM doesn't provide any information as to the resources being accessed, just the service and action, so the best this tool can do is generate policy with wildcard resources.<p>Not ideal, but I guess it's better than running your system with a wide open policy.
I have the need to run client-side monitoring for AWS Lambda functions, but haven't managed to figure out yet what's the easiest option to do so.<p>While I could point AWS_CSM_HOST to some external IP-address, the lack of encryption and authentication makes that pretty nonviable. Alternatively I could put the AWS Lambda functions into VPC, but I'd prefer a less invasive change to the AWS Lambda functions.<p>Does somebody here have a better solution for that?
I can’t really judge the usefulness of this tool as I’m not that familiar with IAM, but I’d be wary of using this in a work situation because I would be really worried I’d accidentally search for “imlive”, which is an adult cam site.<p>Maybe I’m just being paranoid but it feels like if I unintentionally named my super useful and totally innocuous project “poorNHub”, I’d want someone to point out how that might cause problems down the line for adoption.
would it be possible for this to be hooked up to existing serverless frameworks? it would be great if something could scan the code and generate an IAM policy.