the cute answer to all this is always: how do people think your service accesses the secret vault? its anlther credential.
the real issues are tougher, like why does this one cred have access to all these other creds, and how or if they were auditing usage of that cred from authorized client devices.. but all of these problems take a lot of effort and care to solve. and as history has shown, you only have to mess up once.
I agree but an api key for a PAM service will get you constrained access (ideally) to a specific resource instead of a kerberos ticket you can take with you as part of your ticket collection. It's supposed to be better but granting the resource permission like GCP does is probably better (but messier too).
for sure; the real failure in this setup was again, having a single credential with access to so many other critical secrets. I have yet to see a secret vault that had good analytics for this kind of thing - it assumes you have designed your secret hierarchy and permissions appropriately.
ideally, there would be a warning for identities with access to too many secrets.
the real issues are tougher, like why does this one cred have access to all these other creds, and how or if they were auditing usage of that cred from authorized client devices.. but all of these problems take a lot of effort and care to solve. and as history has shown, you only have to mess up once.