It reminds me a lot of .Net Core's newish "Secret Manager." They created a user profile storage vault that's outside the deployment/source code path (like ENV

It reminds me a lot of .Net Core's newish "Secret Manager." They created a user profile storage vault that's outside the deployment/source code path (like ENV variables), and then for some inexplicable reason tell you not to use it in production without good justification anywhere and to use their paid service instead ("Azure Key Vault" $3/100K requests) which is multiple extra points of failure (even ignoring Azure's reliability problems). Naturally people will repeat Microsoft's advice verbatim without justifying it themselves like this SO answer[0]: > Don't use app secrets in production. Ever. As the article says DURING DEVELOPMENT. But WHY?! And the article they linked doesn't tell you WHY either, just points to a paid service. And when these people get poked for an explanation, they just wrap the same secrets in another layer of abstraction, but really haven't changed the security of the operations they're performing. For example if a server node gets compromised and that node is authorized to make requests to "Azure Key Vault," it too can request the keys. The abstraction may make sense for public-private key scenarios where the actual private certificate is never returned, but a lot of what the "Secret Manager" returns are raw database credentials and encryption keys, making this paid abstraction more beneficial for centralized management than actual security. If people want to argue for more abstraction: Fine. But they have to explain the logic behind the security. [0] https://stackoverflow.com/questions/39668456/how-to-deploy-asp-net-core-usersecrets-to-production https://stackoverflow.com/questions/39668456/how-to-deploy-a...