How do I stop one service from reading another service's password?

Give each service its own identity and grant that identity only the credentials it actually opens at run time. Then test the claim by presenting one service's identity and trying to read a password that belongs to another service: the read has to fail, and the refusal has to be recorded.

The natural guess is that two services in the same namespace, the same virtual network or the same cluster can be trusted with each other's passwords. That guess fails because location is not authorisation. The secret store answers a request based on the identity presented, not on which subnet the request came from. If the image resizer and the payments worker present the same identity, they are the same principal to the store, and the image resizer can read the payment key, the signing key, the mail credentials and the database password. The image resizer is also the component most likely to be running somebody else's code, since it parses files uploaded by strangers. A shared identity makes every compromise as wide as the estate.

Put numbers on that product. If the estate has 12 identities and each can read 40 credentials, the grants in force are $12 \times 40 = 480$. If each identity is cut to the one credential its own code opens, the same 12 identities give $12 \times 1 = 12$ grants. The reduction is $480 - 12 = 468$ grants. None of those 468 were doing useful work; they were reach. Scoping does not reduce the number of identities or the number of credentials. It reduces the second factor, and the product is what an attacker gets after one component falls.

Do not build that list by asking the team what the service needs. The answer from memory names the obvious database and the obvious queue, and omits the metrics backend, the feature flag service, the internal search index and whatever a script added two years ago. Read the code instead: grep for every place a connection is opened and list the credentials those connections need. Then watch a full reporting cycle of what the component actually reads from the store, because the path that only runs during the quarterly job is the one that breaks. Grant exactly that list to a new identity, deploy it to one instance first, and leave the old grant in place until the reporting cycle has passed. Then remove the old grant.

There is one arrangement that defeats all of the above. Every service connects to the same database as the same database user. The secret store can have an identity per component and a careful grant for each, and it achieves nothing for that credential, because the value each component is permitted to read is the same value. If the payments worker and the report generator both read a password called app_rw, scoping who may read app_rw does not stop either one from using it. The fix is at the database end: give each component its own database account, its own password, and privileges matching what it does. Read-only where it only reads, no access to tables it never touches. Then the scoped credentials are different values, and the store-side scoping means something.