Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iamlive – Generate an IAM policy from AWS client-side monitoring

github.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#11

Post by uzakov »

gingerlime wrote: post #10
joshuanapoli wrote: post #6

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. 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 o…

could you expand on that? my familiarity is very limited with IAM (as fun as getting teeth pulled), and this sounds interesting.

I can try to explain it in a simplified fashion: When provisioning entities (EC2 instances for example) you go through certain settings (for this example I am talking about a manual provisioning through the UI, not IaC, CLI etc) and one of the things you can do is give EC2 instance a tag. There are a number of reasons to do tagging, to name a few: To make it easier to find a particular instance, cost optimisation, see who owns it. After this you write a policy that says what user/entity can do. This policy can take advantage of the tag, to say: "Only user, who has a tag XYZ can stop this EC2 instance that has tag XYZ" Let me know if that does not make sense and I can go a level simpler

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#13

Post by zackmorris »

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.

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!

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#14

Post by uzakov »

zackmorris wrote: post #13

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. I found IAM to be an anti-pattern. I grew up on the Mac in a sandboxed, single-user environment with…

Hey! So to touch on a couple of points: Scott Piper is probably one of the most known AWS sec experts, check out his websites. https://summitroute.com/blog/

"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?

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#15

Post by coredog64 »

joshuanapoli wrote: post #6

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. 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 o…

In theory, ABAC solves a lot of problems. In practice, there’s no mandate for AWS product teams to support ABAC in a consistent fashion.

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.

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#17

Post by arduinomancer »

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.

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.

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#18

Post by rasguanabana »

zackmorris wrote: post #13

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. I found IAM to be an anti-pattern. I grew up on the Mac in a sandboxed, single-user environment with…

On one hand you have people setting wildcards in IAM policies for development phase (and forgetting to close them down afterwards). It’s hard to figure out permissions beforehand - this would help in these cases, but still taking IAM setup deduced from your traffic does not mean this setup is secure.

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.

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#19

Post by ttul »

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.

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.

Re: Iamlive – Generate an IAM policy from AWS client-side monitoring

#20

Post by zackmorris »

uzakov wrote: post #14
zackmorris wrote: post #13

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. I found IAM to be an anti-pattern. I grew up on the Mac in a sandboxed, single-user environment with…

Hey! So to touch on a couple of points: Scott Piper is probably one of the most known AWS sec experts, check out his websites. https://summitroute.com/blog/ "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?

Ya after writing it, I think what's going on is that I do everything declaratively now. So it's great that AWS lets us create the AWS policy files rather than making us manage permissions through code.

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.

Post reply on HN