There appears to be more discussion happening on the CloudFormation side of this, even though some comments claim this Glue vuln is actually worse: https://news.ycombinator.com/item?id=29922522

ex-AWS: to this day I don’t know who originally green lit the idea of a Service Linked Role where customers are forced to accept and AWS developers just jam way more permissions that the service actually needs because of laziness/incompetence

The issue with with these roles that I don't understand, why can't they in inherit customer context?

Ie, I give an SLA access to my data. But the callee has to be an account role already. So when the SLA goes to access my data, that can only be my data. This is sort of your templated role idea, maybe managed templated roles, but I basically create a service role, and of course because its local to my account, there is no access by the service generally to customer data.

I'd suggest a bit of "respect what came before" and Chesterton's Fence here. A couple of thoughts from a principal at AWS who's had to use, create, and review a handful of Service Linked Roles:

The absolutely most important aspect is that requiring individual role & permission management for each service/feature is a HUGE painpoint for both customers and service teams. Having AWS "just do it" on the customers behalf simply eliminates a lot of friction in your app, the console, the CLI, etc.

Some services do support templated _service roles_ but these are difficult to maintain with the appropriate permissions over time. There are other services that will allow customers to provide (via API param) a customer managed role that the service can assume. That is better for sophisticated customers who want more control, and know the permissions necessary. But is substantial muck and another thing to get in the way of their actual intent for many (most?) customers. Both of the later approaches with customer managed roles also introduce problems with role proliferation, aging security policies, opaque authnz failures, incompatibilities as services add new features, etc.

Customers arent "forced" per se to use any Service Linked Roles (SLR). They absolutely have control over SLRs with APis like CreateServiceLinkedRole & DeleteServiceLinkedRole. Yes, its true that you may not be able to use a service without a specific SLR. But that's an issue of dependency management, tied up in the other points.

SLRs are only created by the customer via CreateServiceLinkedRole or on their behalf when accessing a service API (or similar interaction) that requires a SLR to function. Again, visible & controllable by the customer. It's not opaque nor is it forced on customers who dont use the associated service/feature.

Service Linked Roles are being improved in the last few years with much more explicit naming, permissions, and documentation of why/when/how they're being used. It's important that this is all done in the context of the customers account, and entirely visible through things like managed policies & cloudtrail.

Yes there are some roles (and other managed IAM policies) that are quite broad. This is an ongoing trade off between friction and minimal surface area. Unfortunately "fixing" these policies is also at odds of the principle around providing a stable, predictable, cloud that does not break or deprecate functionality unless absolutely necessary.

My own take is that SLRs are the best available option at the moment. I'd love it if every service/API provided an optional way to pass a customer managed role, accept a templated service role via console or cloudformation, or by default create & use an appropriate Service Linked Role. But that's a big change in a huge surface area which may or may not be appropriate.