Show HN: SecretCrypt – Keeping secrets in plain sight
zemanta.github.io
Show HN: SecretCrypt – Keeping secrets in plain sight
1–10 of 38 posts
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#2Repository: https://github.com/Zemanta/go-secretcrypt
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#3It should be made clear that this requires AWS KMS, and for automatic decryption, EC2 (so that the instances can be associated with an IAM role that has key decryption permission).
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#4Using KMS is a good idea, but I'm not really sure what this package gives you - just a simple abstraction / cmdline to deal with it?
This would be better if it could use the aliases directly, so you could have one config across N environments and separate them by AWS keyspace.
Having to embed the full KMS path for each key gains you the secret management they claim (which is a good thing) but sacrifices ease of use. That said, aliases wouldn't help with missing secrets or misconfiguration across environments, and its a lot easier to audit string-for-string to match your KMS store, so either approach has its pluses and minuses.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#5> Since the configuration file is kept in the same repository as the code, configuration options or secrets can easily be changed or added by developers themselves.
This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#6> Since the configuration file is kept in the same repository as the code, configuration options or secrets can easily be changed or added by developers themselves. This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
Yup. Storing config and code together is a violation of the Twelve-Factor App methodology. https://12factor.net/config
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#7> Since the configuration file is kept in the same repository as the code, configuration options or secrets can easily be changed or added by developers themselves. This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
Unless your code is like 99% of all the code I've seen ,where you only deploy to a handful of locations, and it's really handy to just say '-profile=stage'. Besides, including config in the build does not preclude being able to pass it in as well.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#8> Since the configuration file is kept in the same repository as the code, configuration options or secrets can easily be changed or added by developers themselves. This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
[deleted]
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#9> Since the configuration file is kept in the same repository as the code, configuration options or secrets can easily be changed or added by developers themselves. This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
Yup. Storing config and code together is a violation of the Twelve-Factor App methodology. https://12factor.net/config
Is this methodology accepted as state of the art or used by the author of this article? I don't see why breaking this particular set of rules is an issue.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#10> Since the configuration file is kept in the same repository as the code, configuration options or secrets can easily be changed or added by developers themselves. This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
You can have per environment config files