The "write-only" feature could be implemented without a third-party with a keypair.
Show HN: SecretCrypt – Keeping secrets in plain sight
11–20 of 38 posts
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#12The "write-only" feature could be implemented without a third-party with a keypair.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#13> 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.
We deploy code to 3 datacenters so we simply have 3 config files in the repository. Deploy script then decides to link the correct config for the environment.
If you want to run local environment you can simply create your own configuration.
I don't really see what you gain by moving configuration files into a separate repository.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#14What happens if Amazon's KMS service is down - does that break the app or can you operate ok without it ?
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#15> 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.
We deploy code to 3 datacenters so we simply have 3 config files in the repository. Deploy script then decides to link the correct config for the environment. If you want to run local environment you can simply create your own configuration. I don't really see what you gain by moving configuration files into a separate repository.
That's pretty standard and accepted. Don't know what gp is talking about.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#16What happens if Amazon's KMS service is down - does that break the app or can you operate ok without it ?
We decided to decrypt secrets on service startup so if KMS is down during the deploy we can stop the deploy after first server fails to start. Not perfect but good enough for our use case.
In case of catastrophic KMS failure we can always manually replace secrets with plaintext and revoke them afterwards.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#17> 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
I keep hearing this "violation of Twelve-Factor" statement.
The Twelve-Factor Methodology is a sensible set of guidelines/defaults for building a modern app, as written by Heroku.
Don't blindly follow it As It Was Written without thinking. Seriously, do what works. Use your brain. Using this statement as an argument against other methods is sending the wrong message.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#18How is this different from/better than Stack Exchange's blackbox[0] which doesn't require a third-party service (just plain-ole gpg) and is written in bash?
[0] https://github.com/StackExchange/blackbox
P.S.: I think the image looks aesthetically pleasing, but why is it there? It's a scaled-down 1,600x680px image that costs me 140KB and doesn't add anything to the article; what's worse is that it's not even a nice banner image, it's just smack dab in the middle of the article.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#19So... storing your secrets in AWS then... and not in plain sight.
Re: Show HN: SecretCrypt – Keeping secrets in plain sight
#20> 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.
We deploy code to 3 datacenters so we simply have 3 config files in the repository. Deploy script then decides to link the correct config for the environment. If you want to run local environment you can simply create your own configuration. I don't really see what you gain by moving configuration files into a separate repository.
> If you want to run local environment you can simply create your own configuration.
Externalizing config forces you to cleanly handle local environments as well. There's nothing special about them.
I generally recommend having an env.example file listing out required environment variables with sensible local defaults. This eases onboarding a new developer or even an existing developer on a new machine.
> I don't really see what you gain by moving configuration files into a separate repository.
Because config and code should be kept separate. Updating the database that your production app is using is not a code change. It's a config change.
Setting up a new CI environment should not require pushing new code.
If you have a production issue in version X, separating code and config allows you to reproduce it using an isolated database/mq/foobar service. It's exactly the same code.