| Hey HN, we are Daniel and Tal, Co-founders of Slauth.io (https://www.slauth.io). Slauth auto-generates IAM policies in order to save engineering time and make your policies more secure. 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 |
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).