Show HN: Slauth.io (YC S22) – IAM Policy Auto-Generation
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://slauth.io
It sounds like your product is very similar, so you might be able to borrow some ideas.
[0]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...
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).
you can do this for free
https://github.com/JamesWoolfenden/pike
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.
Kudos on launch, will check your beta
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.