Hacker News Reader

It's usually rely on some globa mechanims by the underlying architecture.

Example, if it's AWS it may rely on ec2 instance role, to allow it access to the secret manager.

If it's kubernetes, it can be done through k8s token mount, basically allow token in namespace access the vault, and the token(which is generated and manage by k8s, which is just a JWT btw) is mounted into your pod.

There are often multiple sets of credentials that you need to pass to a microservice, some of which may be shared between multiple instances of the service or even between multiple services. Changing them would require plenty of case-specific updates to service configurations or just one update in the vault. By reducing the amount of work to update the credentials you also reduce security and quality-related risks.

I don't know and I don't need to know (I'm a mere dev -- no "ops" in my role). And, yes, this client has very high compliance requirements.