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

Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

news.ycombinator.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#71

Post by nutbear »

Eumenes wrote: post #54

The problem with IAM from my experience is it's never truly owned by a single entity. If you have an IT team, its sometimes them. Sometimes its devops, sometimes security. However as a startup grows, the owners change. Policy is rarely developed from the ground up and more patchwork to accomodate teams or timelines

Yes. Good points. Agreed with patchwork as sometimes IAM can take a backseat to different priorities such as application development or feature development.

There's a couple different models for IAM ownership. At some places, the application teams own IAM along with the application. Sometimes, it's owned by central teams (such as security).

And agreed, with companies growing and changing, ownership changes as well.

Those factors can all complicated IAM development and policy maintenance as it becomes more difficult to find the right fit for IAM to application. For that, it would require someone who knows exactly what the application needs access to and the IAM actions taken as well as how to configure IAM.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#72

Post by teaearlgraycold »

Eridrus wrote: post #31

IAM is horrific, but I feel like it's not really the application-specific stuff that is annoying for me, it's the stuff that AWS wants configured for AWS features to work and the fact that the error messages when you get it wrong are useless at pinpointing your mistake, when you do not know that access is mediated by IAM. Just as an example, I setup a containerized app on Fargate with a custom role, and the need to c…

I just set up an S3 bucket - probably the most common use case for IAM policies. My policy file was invalid in a way that AWS never warned me about and looked good to my untrained eyes. After a few hours of debugging GPT-4 was able to explain I needed to break up my rules into bucket-level and key-level sections. Afterwards the 403 errors went away.

Just sharing my story. IAM sucks and GPT-4 is a good backup for configuring it.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#73

Post by Eridrus »

teaearlgraycold wrote: post #72
Eridrus wrote: post #31

IAM is horrific, but I feel like it's not really the application-specific stuff that is annoying for me, it's the stuff that AWS wants configured for AWS features to work and the fact that the error messages when you get it wrong are useless at pinpointing your mistake, when you do not know that access is mediated by IAM. Just as an example, I setup a containerized app on Fargate with a custom role, and the need to c…

I just set up an S3 bucket - probably the most common use case for IAM policies. My policy file was invalid in a way that AWS never warned me about and looked good to my untrained eyes. After a few hours of debugging GPT-4 was able to explain I needed to break up my rules into bucket-level and key-level sections. Afterwards the 403 errors went away. Just sharing my story. IAM sucks and GPT-4 is a good backup for conf…

I guess I did not try to deal with anything key related, so that's probably why it was simpler for me.

I do agree that everything about it is horrific, though I'd be surprised and impressed if an LLM were able to generate your key setup from scratch.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#74

Post by nutbear »

lijok wrote: post #52

How are you dealing with invalid policies generated by GPT? For example, in your loom video and the gif on the website, the resource for the s3:PutObject permission is incorrect: it should be "arn:aws:s3:::my_bucket_2/*" not "arn:aws:s3:::my_bucket_2". Does this support resource policies? If so, how are you ensuring serious security vulnerabilities such as confused deputy are not introduced by this tool?

Good catch on the bucket vs object level permissions with S3 and s3:PutObject.

I'd also be curious for future plans with resource policies as that's another layer of complexity to manage - where the resource policy would manage access to potentially many applications -> 1 resource. Vs 1 application -> many resources which I think is the use case Slauth is solving for initially.

Confused Deputy would be interesting, could be done via Condition Keys such as SourceArn and SourceAccount, but gets complex for cross-account use cases.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#75

Post by vasco »

DanielSlauth wrote: post #9
verdverm wrote: post #4

Earlier quoted context omitted.

I'm not your target user, I don't feel the priority on this problem even though our permissions are more permissive than we'd like. Thing is, to rein them in typically requires application changes. You cannot just sprinkle magic LLM dust on IAM and make things better. My concern is for those who blindly trust LLMs. Security posturing is not the place to be an early adopter of AI tools. You have to understand both IAM…

First of all its pretty awesome your permissions are very tight. You are definitely on the other side of the spectrum compared to the rest. I get it that there is a lot of skepticism because of people hyping LLM's so indeed for now we use it as Copilot and not the driver. Hopefully you can agree though its pretty random that we are still manually creating IAM policies and need to get accustomed with the thousands of…

To add a plus one here, as soon as I learned there's LLMs involved this became a non starter to me. I'd rather have less granular policies than risk some LLM doing something crazy.

I can justify to management that we have limited time for IAM and something was missed that we can fix / create tests / scans for after an incident. It's harder to explain that we chose a vendor that uses a non deterministic tool that can hallucinate for one of the most core security pieces of the puzzle.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#76

Post by Eridrus »

lasermike026 wrote: post #34
Eridrus wrote: post #31

IAM is horrific, but I feel like it's not really the application-specific stuff that is annoying for me, it's the stuff that AWS wants configured for AWS features to work and the fact that the error messages when you get it wrong are useless at pinpointing your mistake, when you do not know that access is mediated by IAM. Just as an example, I setup a containerized app on Fargate with a custom role, and the need to c…

You get used to it.

Sure, you can get used to anything, but it still sucks and is worth trying to improve the situation on.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#77

Post by janalsncm »

My question is why I would need another service to do this when I’m already paying for gpt4 and I can already ask it detailed questions to generate an IAM config. Essentially you have built a GPT4 which does one thing, but I can easy get GPT4 that does many things.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#78

Post by DanielSlauth »

lijok wrote: post #35

I'd like to challenge you on what seems to be the main claim behind why Slauth is a necessary product: "the amount of money that is being spent on tooling to scan for IAM misconfigurations in the cloud". 1. The tooling you're quoting specifically, wiz.io and ermetic.com do an incredible amount more than just "scan for IAM misconfigurations". In fact, I understand that to be one of their most insignificant features. Y…

>I'd like to challenge you on what seems to be the main claim behind why Slauth is a necessary product: "the amount of money that is being spent on tooling to scan for IAM misconfigurations in the cloud.

The quote you use got me to further research the market and speak to users of those toolings. From speaking to the users it was evident that the amount of misconfigurations being deployed wasn't being reduced.

I imagine users of cloud scanning tools would also use a pro-active tool like Slauth or any other shift-left tool that would aim at preventing as opposed to reacting.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#79

Post by verdverm »

DanielSlauth wrote: post #78
lijok wrote: post #35

I'd like to challenge you on what seems to be the main claim behind why Slauth is a necessary product: "the amount of money that is being spent on tooling to scan for IAM misconfigurations in the cloud". 1. The tooling you're quoting specifically, wiz.io and ermetic.com do an incredible amount more than just "scan for IAM misconfigurations". In fact, I understand that to be one of their most insignificant features. Y…

> I'd like to challenge you on what seems to be the main claim behind why Slauth is a necessary product: "the amount of money that is being spent on tooling to scan for IAM misconfigurations in the cloud . The quote you use got me to further research the market and speak to users of those toolings. From speaking to the users it was evident that the amount of misconfigurations being deployed wasn't being reduced. I im…

I suspect you will have a better time selling the tool as a double checker than an author. As others have pointed out, LLMs cannot be trusted to create security policies, but they may be accepted as something that can catch mistakes, because we are busy and the attention needed is not always there.

At the same time, it will create noise in a PR, it will be reliably wrong, so it is not really about saving time, but more about always having an extra (junior) reviewer, it's only going to catch the simple things. You will have to work hard to improve the signal to noise ratio. Your current examples are all very simple and do not reflect real world complexities. I'm very much doubt ChatGPT has enough context length for devising real world IaC from source code, or even checking it. How many times will the code changed in a PR require knowledge about code not changed in a PR?

Post reply on HN