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.
Assuming it doesn’t cause networking issues, IMO the best approach is to finely scope AWS accounts. They’re free, and Amazon includes some reasonable tools for working with them. The major downside is the double charge on Transit Gateway traffic.
AWS is untenable.
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 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.
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.
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.
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.
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've used it mostly for debugging and temporary monitoring of service calls.
https://summitroute.com/blog/2020/05/25/client_side_monitori...
It seems difficult to make sure you actually exercise every path of your app so that it makes every API call.
It makes me wonder if live monitoring or static analysis is the better approach.
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.
However as a caller, you need multiple levels of caching underneath the hood (all built by IAM team). That's part of the reasons why you can't use IAM as an external service.
IAM is also eventual consistency - that's why if you modify the policy doc it takes seconds to reflect in your service calls :) (sometimes even minutes). IAM outages can and will take down multiple AWS services.
> If so how would they be evaluated consistently across different languages?
Internally everything is JVM AFAIK :). If you go out of the JVM world in AWS you'll have to deal with this problem yourself, which can be painful.
The caching layer must also be quite complex! But thanks for settling this for me.
It’s not limited to API gateway or EC2.
Not ideal, but I guess it's better than running your system with a wide open policy.
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.
Does somebody here have a better solution for that?
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.
One good solution - turn on adult content blocking on firewall. Saved me once or twice if you typo, missearch etc. I'm usually like huh when it blocks? Then oh...
On the other hand you have complex architectures and no real overlap in their authorization patterns. It’s impossible to automate creation of secure "sandbox" setup for your specific use case.
You can’t really delegate security of your architecture to a single service - you need to address it yourself. Security can be implemented only in the service, not as a service.
Maybe AWS could provide a way to track access attempts and then have an interface for the user to grant them one by one. I understand that this might be challenging to design, but I view these sorts of challenges as the "real work" of computer science, otherwise there's just nothing there.
I encounter that a lot when I have a preconceived notion of the heart of a strategy (including edge cases), only to find that it wasn't addressed, and in fact wasn't even mentioned.
Yes these things are hard, but Amazon has billions and billions of dollars.
[1]https://developer.microsoft.com/en-us/graph/graph-explorer
"Any approaches to formally proving that IAM roles and permissions are secure would be greatly appreciated! " Are you looking for a way to see that you have set up your policies correctly?
But I want to see the infrastructure as a big spreadsheet, turn on a policy, and see the accessible services highlight. basically I need something like an acceptance/integration test that proves that my permissions work like I think they do.
Without something formal like that, I can't help but feel that IAM is risky to rely on alone. To the point that, I would be wary of using it, and even view it as more of a liability than a useful tool. This is really a general conceptual issue with the abstraction of roles/permissions from a computer science perspective. My gut feeling is probably that the general authentication-based logins of the open internet and circles of trust are better mechanisms for securing services. That said, I do really appreciate that we can reference security group ids in new security group rules. Once I started chaining the references like that, and having subnet rules in a central place, things worked more smoothly.
I would never use roles/permissions for new development though is what I'm trying to say (whether for web development or web hosting). I don't think it makes sense to screen access by which network was used, or the source IP of the user trying to gain access. These are somewhat antiquated notions that make sense for sysadmins, but I don't think they make sense for the vast majority of use cases that web developers encounter. We could just use the open web's CLIENT_ID=abc, CLIENT_SECRET=xyz pattern for all AWS services. But maybe there's some advantage with roles and permissions that I'm not seeing.
Sorry I come off as Negative Nancy, but this issue really concerns me, and I don't see much talk about it on sites like Stack Overflow.
Zelkova uses automated reasoning to analyze policies and the future consequences of policies. This includes AWS Identity and Access Management (IAM) policies, Amazon Simple Storage Service (S3) policies, and other resource policies. These policies dictate who can (or can’t) do what to which resources. Because Zelkova uses automated reasoning, you no longer need to think about what questions you need to ask about your policies. Using fancy math, as mentioned above, Zelkova will automatically derive the questions and answers you need to be asking about your policies, improving confidence in your security configuration(s).
https://aws.amazon.com/blogs/security/protect-sensitive-data...
Maybe start at Provable Security: https://aws.amazon.com/security/provable-security/
> "But I want to see the infrastructure as a big spreadsheet, turn on a policy, and see the accessible services highlight. basically I need something like an acceptance/integration test that proves that my permissions work like I think they do."
This problem can be solved by having your infrastructure etc as Terraform templates, and writing unit tests for those. Additionally you can use 3rd party solutions, depending on what you mean by "see the accessible services highlight"
> " I don't think it makes sense to screen access by which network was used, or the source IP of the user trying to gain access."
I would say this is additional thing you would do, but not the only.
> "But maybe there's some advantage with roles and permissions that I'm not seeing."
Let me/us know and maybe either me or someone else can help you. Hopefully my message didnt come as condescending. PS I dont work for AWS