Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SecretCrypt – Keeping secrets in plain sight

zemanta.github.io

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#21

Post by 45h34jh53k4j »

I like this design. Infrastructure as code. Store your config data in you repo. Screw 12 factors.

You can do this with the inhouse AWS tools, awscli and boto3 for python This was for use within a python lambda function so i used the secrets in a seperate file, but no loss of generality here.

* Create your keys in KMS via Web UI or otherwise * encrypt your secrets before commit aws kms encrypt --key-id alias/TokenKey --plaintext fileb://unencrypted_token --output text --query CiphertextBlob > encrypted_token

Decrypt the token from your python lambda function with boto3

kms = boto3.client('kms') token = kms.decrypt(CiphertextBlob=base64.b64decode(token_encrypted))['Plaintext'].decode('ascii')

The blob from KMS contains the appropriate fields for decryption from their service. Give the lambda role rights to decrypt with the key.

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#22

Post by andreasklinger »

mafro wrote: post #17
NickBusey wrote: post #6

Earlier quoted context omitted.

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.

what's your counter argument/proposal ?

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#23

Post by hueving »

andreasklinger wrote: post #22
mafro wrote: post #17

Earlier quoted context omitted.

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.

what's your counter argument/proposal ?

They are just guidelines. "violating them" means absolutely nothing so claiming so adds nothing to the conversation.

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#24

Post by yayitswei »

chrisdotcode wrote: post #18

How 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 ba…

That's the company logo, so it's the ad that makes this blog post possible.

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#25

Post by nickpsecurity »

mafro wrote: post #17
NickBusey wrote: post #6

Earlier quoted context omitted.

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.

The linked part about config makes sense. It's a specific instance of a general concept that shows up in hardware and software engineering. That's that things that reusable things that don't change should be separated from those that change often.

In this case, we have code and [configuration] data. The data can and will vary considerably while reusing the same code. They should be separate so data changes don't require recompilation. Further, any change of code can change its behavior. Better to have code that's already vetted via review and testing to handle specific types of input data. That way you can keep changing the data without re-assessing the code. There's also a minor benefit in efficiency when you can re-use binaries already created and integration tested while just generating new configuration data. Those minor things can add up if you're constrained in CPU/memory.

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#26

Post by nickpsecurity »

andreasklinger wrote: post #22
mafro wrote: post #17

Earlier quoted context omitted.

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.

what's your counter argument/proposal ?

Here's my interpretation of the link:

https://news.ycombinator.com/item?id=12344971

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#28

Post by hamax »

koolba wrote: post #20
hamax wrote: post #13

Earlier quoted context omitted.

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 rea…

I'm sorry but I really don't understand how having env.production.toml commited in the same repository as code makes anything that you said impossible/more difficult.

I can always grab the build from production and run it locally with the modified config.

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#29

Post by hamax »

nickpsecurity wrote: post #25
mafro wrote: post #17

Earlier quoted context omitted.

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.

The linked part about config makes sense. It's a specific instance of a general concept that shows up in hardware and software engineering. That's that things that reusable things that don't change should be separated from those that change often. In this case, we have code and [configuration] data. The data can and will vary considerably while reusing the same code. They should be separate so data changes don't requ…

> data can and will vary considerably while reusing the same code.

This is the complete opposite of my experience. We deploy new code to production 10 times per day and change configuration a couple of times per month.

What do you keep in configuration that changes this often?

Re: Show HN: SecretCrypt – Keeping secrets in plain sight

#30

Post by daenney »

otterley wrote: post #3

It 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).

I think that's pretty clear in the article that's linked. It explicitly mentions AWS KMS and its reliance on it and how IAM roles are used to grant access to a secret.

It also states that KMS isn't a requirement, you can use Vault too.

Post reply on HN