Launch HN: Slauth.io (YC S22) – IAM Policy Auto-Generation
32 comments
> 3 IAM policies per month
This is... Not a useful number of policies. I've got a terraform setup for my one person business and I probably have two orders of magnitude more policies than this.
Who is this targeted at? Which policies am I supposed to use these three on? What kind of service only has three policies? How am I supposed to evaluate your service with this small number of policies? The problem is that they might be the "perfect" global maximum goodness policies, but they exist in a web of policies that all need to be correct together. So three does nothing to show me how good your service is, and it's not useful (afaict) for ongoing work.
Here's how I can see you fixing this:
- Just charge me. Give me a trial. Let me pay up front and have a money back policy. Let me generate what I need and see whether it's useful.
- Give me unlimited free policies, but charge for things like tightening down resource access (e.g., narrowing access to specific S3 buckets instead of just narrowing access to S3).
This is... Not a useful number of policies. I've got a terraform setup for my one person business and I probably have two orders of magnitude more policies than this.
Who is this targeted at? Which policies am I supposed to use these three on? What kind of service only has three policies? How am I supposed to evaluate your service with this small number of policies? The problem is that they might be the "perfect" global maximum goodness policies, but they exist in a web of policies that all need to be correct together. So three does nothing to show me how good your service is, and it's not useful (afaict) for ongoing work.
Here's how I can see you fixing this:
- Just charge me. Give me a trial. Let me pay up front and have a money back policy. Let me generate what I need and see whether it's useful.
- Give me unlimited free policies, but charge for things like tightening down resource access (e.g., narrowing access to specific S3 buckets instead of just narrowing access to S3).
Thank you for the feedback!! We needed something to start of with but your arguments are very fair so we will have to change it.
Would you like to sign up for the Beta and give it a try? Would absolutely love your opinionated feedback :D
Also, how much would you pay? Could you give us some insights there.
If you dumped out terraform code for policies, I'd probably pay up to $150/mo for some very reasonable number of policies (200?).
Nice! Will work on the pricing tiers and features.
Regardless, would love for you to test it out and we can agree on the above $150/mo for 200 policies :)
https://flosell.github.io/iam-policy-json-to-terraform/
you can do this for free
you can do this for free
I don't need to convert JSON to TF. I need someone to tell me which policies are too lax and give me the Terraform code that should replace them.
The fact that there is a entire service because AWS is so confusing is hilarious.
We eventually want to make this agnostic and have it work for all cloud vendors. Pretty complex to write policies if you are running multi-cloud!
Could you expand on how this compares to IAM's built-in Access Analyzer[0]?
[0]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...
[0]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...
We have found several "problems" that we think can be done better
1) CloudTrail requires to run for a duration of time before suggesting a policy which means long time until getting value. What do you do until the suggestion? Run a less secure policy?
2) CloudTrial actually doesn't log all events so we are using either AWS SDK metrics or a proxy to make sure we get all activity
3) Integrations with Terraform, Git repository in order to make it easy to use in day to day
4) Hopefully in the future we can extend to other cloud vendors :)
To add some more pros, Access Analyzer has limits on the amount of policies you can generate at a certain time and doesn't support all AWS services
How would you compare your offering to https://github.com/iann0036/iamlive (an opensource implementation of IAM generation from client-side monitoring or proxy, released in Feb 2021)?
We definitely love iamlive! Iamlive is easy to operate manually on a single instance, and outputs the results to the terminal, making it great for local exploration. We focus on observing IAM at scale, collecting data from multiple sources - local / staging / per-developer environments etc. We know to find the relevant IaC code piece and generate policies in the form of Git Pull Requests.
Are you familiar with ConsoleMe from Netflix? https://netflixtechblog.com/consoleme-a-central-control-plan...
It sounds like your product is very similar, so you might be able to borrow some ideas.
It sounds like your product is very similar, so you might be able to borrow some ideas.
Thanks! We were partially inspired by it. Our approach is slightly different - we believe we shouldn't be the focal point of IAM but rather integrate with the existing tools organizations use such as Git, Terraform etc
Thanks!! Looks really good. I hope we can contribute from a different angle by focussing on the creation of the policy and ideally expand beyond AWS :) Thanks for the heads up
Per-resource IAM policy generation alone is not even half good enough. Most AWS services have complex IAM policy requirements that are unique to a specific AWS service or product, and within each there is typically a subset of policies being necessary (less frequently, the entire lot of them) – depending on which parts of the service/product are used, e.g. take a look at https://docs.aws.amazon.com/appflow/latest/userguide/securit...
Oftentimes, resource policies require condition or context keys to be supplied, e.g. https://docs.aws.amazon.com/glue/latest/dg/using-identity-ba...
Or a S3 cross-account replication policy that requires a specific condition to be able to decrypt and re-encrypt the data in the S3 bucket. KMS policies, in general, are notorius for mandating conditions and context keys – at once.
Cross-account IAM resource policies are even more complex, as they require policies to be configured in both accounts, and the policy is different in each of accounts; take Glue as a simpler example: https://docs.aws.amazon.com/glue/latest/dg/cross-account-acc... Such knowledge can't be [easily] derived from parsing and analysing a terraform codebase alone.
Without maintaining a comprehensive repository of AWS services and IAM policy generation rules specific to each of the AWS services that can support a specific permutation of product features used in a project, I fail to see how this product is useful or what it can do beyond trivial «grant the service instance ABC access to the service DEF by using DEF's ARN». Which is… frankly not very useful on its own.
Oftentimes, resource policies require condition or context keys to be supplied, e.g. https://docs.aws.amazon.com/glue/latest/dg/using-identity-ba...
Or a S3 cross-account replication policy that requires a specific condition to be able to decrypt and re-encrypt the data in the S3 bucket. KMS policies, in general, are notorius for mandating conditions and context keys – at once.
Cross-account IAM resource policies are even more complex, as they require policies to be configured in both accounts, and the policy is different in each of accounts; take Glue as a simpler example: https://docs.aws.amazon.com/glue/latest/dg/cross-account-acc... Such knowledge can't be [easily] derived from parsing and analysing a terraform codebase alone.
Without maintaining a comprehensive repository of AWS services and IAM policy generation rules specific to each of the AWS services that can support a specific permutation of product features used in a project, I fail to see how this product is useful or what it can do beyond trivial «grant the service instance ABC access to the service DEF by using DEF's ARN». Which is… frankly not very useful on its own.
Thanks!
Didn't know about Pike :) Looks interesting, though it is based on a static analysis approach which has its downsides since it might not look the same as the actual activity.
AirIAM was an inspiration for us - it is generally good to group users together and for finding unused policies. We focus on generating an exact policy per identity.
Didn't know about Pike :) Looks interesting, though it is based on a static analysis approach which has its downsides since it might not look the same as the actual activity.
AirIAM was an inspiration for us - it is generally good to group users together and for finding unused policies. We focus on generating an exact policy per identity.
I have used https://github.com/iann0036/iamlive with great success in the past. On high level, the approach you are describing is iamlive on steroids and UX improved.
Kudos on launch, will check your beta
Kudos on launch, will check your beta
Also a tool that will detect when more permissions are needed will be appreciated. For now it's running `tf apply`, getting 403, searching and reading CloudTrail, changing one permission, goto 1
That's definitely something we are addressing! Would you like to sign up for the beta? Will love getting your feedback and helping you remediate this pain
Thanks! Will have a look. Have you used it? If so, would love to learn what you liked and didn't like
When you need a whole YC-funded startup just to configure permissions of your cloud host, you know something is rotten about this entire industry.
I like the website but I wish I could control the slider between insecure policy and secure policy, it's a bit too fast.
The time to the first content paint on that website is incredibly slow.
Looks great. Any thoughts about expanding to GCP in the future?
Yes def! We wanted to quickly validate the need so started with AWS but if we get good traction we will expand to GCP next :) Feel free to share with AWS users so that we can get going :D
Great idea! I can definitely see this getting serious traction
Website down…?
Getting slower haha... HN is generating traffic but will have to ask Webflow what's going on lol
If you're an engineer, you probably know how tedious and error-prone it can be to manually write IAM policies. We surveyed over 70 engineers and found out that a majority are using or have used wildcards (*) in order to quickly write IAM policies.
By using client-side monitoring or via a proxy, Slauth.io observes all of the API activity and generates a policy based on functionality and least privileges.
Once deployed in a remote environment, or run locally, you will need to run an end-to-end test using a wildcard policy. Slauth will observe the activity, apply its logic based on large amounts of behavioral patterns of the service you deploy, and create a high quality IAM policy.
The IAM policy will be presented through the Slauth Dashboard where it can be copy/pasted or as a pull-request into your Git repository ready to be reviewed. Integrations with IaC services such as Terraform are also available.
Our objective is to automate manual error-prone IAM policy writing in order to increase engineering velocity, reduce friction and harden security.
Would love your feedback on the value proposition and if you would use the AWS SDK or Slauth proxy for onboarding.
Feel free to also sign up for Beta usage! https://www.slauth.io