5 ms·

So the author offers two alternatives: 1. Using docker-secret inside of a Docker swarm 2. Using Keywhiz [1], a Java server together with a FUSE client. This

• thesimon 6y ago
  > not checked into the source code repository Or checked-in, for easy distribution, just encrypted: https://github.com/sobolevn/git-secret https://github.com/sobolevn/git-secret
  • stanmancan 6y ago
    I mean anything encrypted needs to be decrypted, meaning you have to... have the key stored in an environment variable on the server?
    • kevmo314 6y ago
      This would at least alleviate having to know n different env secrets that need to be set.
      • stanmancan 6y ago
        Yeah, it’s convenient but it doesn’t solve the topic of the post, which is “you shouldn’t use environment variables for secret data”
    • R0b0t1 6y ago
      Install the secret for production. For testing you just lock/unlock the secret.
    • rad_gruchalski 6y ago
      Or in a file, like ansible does it.
• Ebanix 6y ago
  https://12factor.net/ https://12factor.net/ Config is the third commandment. IMO it also makes it super easy to swap configs for different environments.
  • wst_ 6y ago
    Did you read the article? Author knows about, mentions it in first sentence and still is against putting secrets there.
    • deleted 6y ago
      [deleted]
• Someone1234 6y ago
  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...
  • lostmsu 6y ago
    Another reason is that you have a single place to store your secrets shared between multiple services. Now you only have one place to update when the secret expires/is revoked.
  • remmargorp64 6y ago
    If I understand correctly, the primary advantage of using a secrets manager is that you can log all of the requests. If your security is compromised, it's compromised, but having at least some kind of auditing can be hugely beneficial from a security standpoint.