Comment by joshuanapoli

I was excited to read your project description. It would be really great to automatically align the security policy for each component with the intent of the component's author. Tightening an overly permissive policy is an awful job. I think that it often has to be done through a long trial-and-error process; remove all the permissions, and add back permissions one by one in response to observed program failures. So it's great to see another way to avoid that tedious chore.

A challenge with Slauth will be to organize the generated policies in a way that makes them legible. I would like the IAM policy to help clarify its intent. Allowing each in-use API endpoint is technically required to let the service work. It might be technically following the principal of least privilege. But the endpoint-by-endpoint rules do a poor job of summarizing the purpose of the policy or how it relates to the service. One way that we do this is by having resource providers declare managed policies that allow use of the resource. So the "encabulator" provider also defines a "mutate encabulator" managed policy. Then services that need to invoke "mutate encabulator" can reference the managed policy. They don't need to compute the ARN of every endpoint. The dependent service doesn't end up with an inline policy that has detailed dependencies on the implementation details of each target resource.