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

Crypto Tools for DevOps: Git-Crypt – Tozny

tozny.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#11

Post by peterwwillis »

alreadygone wrote: post #9
peterwwillis wrote: post #6

Earlier quoted context omitted.

What app? They all take credentials different ways. The ideal would be an unprivileged child talking to a privileged parent, where the child asks for the secret and is authorized by the parent, and then both the child and parent erase the [unencrypted] secret when not in use. If your app doesn't do this, executing some app that then feeds the secret via a file descriptor (pipe/socket/etc) (and hopefully erases all tr…

> (and hopefully erases all traces of it after) Which is a "best effort" at best.

IIRC this is part of why modern credential management stores provide one-time-use tokens for certain services. You can provide the same with quick hacks, it just takes more hacking.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#12

Post by peterwwillis »

yeukhon wrote: post #8
peterwwillis wrote: post #6

Earlier quoted context omitted.

What app? They all take credentials different ways. The ideal would be an unprivileged child talking to a privileged parent, where the child asks for the secret and is authorized by the parent, and then both the child and parent erase the [unencrypted] secret when not in use. If your app doesn't do this, executing some app that then feeds the secret via a file descriptor (pipe/socket/etc) (and hopefully erases all tr…

> "The simplest hack is to use a configuration management tool" > "You can also use a credential management suite for a more robust solution" You have to start somewhere, this is why automated system with credentials isn't a simple task to solve. Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you ne…

I don't think it's quite as complicated as you make it out to be.

1. Write a script that will, when given a specific key, will decrypt a file, extract a specific credential that matches the key, and return it. (Credential Extractor-Writer)

2. Put the CEW file somewhere the devs don't have access. (Credential Store)

3. Make a script to connect to a specific host and port using PKI or public-key auth (HTTPS, SSH), and make it feed a key on stdout, and receive a credential on stdin. (Credential Retrieval Script)

4. Make a script to push new keys out to hosts/services regularly (Host-Service Key Pusher) and a script to change/rotate credentials on the CS (Credential Changer).

(all of that can be implemented with Bash, Openssh, GPG, and 7Zip/Rar/whatever)

For your example, whatever manages Jenkins' configuration can simply call the CRS and save the resulting credential however Jenkins wants it. This covers just about everything except that single point of failure, the CEW file.

To protect that, keep each part of the CEW encrypted by an individual key, so only services requesting their key will get access to the credential, and distribute new keys when a credential is changed. Put expirations on key/credential pairs. Add key signing to everything. You can go farther and plug in google-authenticator and 2FA. Implement a two-man rule. Go crazy.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#13

Post by ipmb »

tptacek wrote: post #2

Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.

Ordinary devs could have access to all the encrypted secrets without having access to the keys to decrypt them. If that's the case, the laptop is no more a risk than the git remote.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#14

Post by yeukhon »

peterwwillis wrote: post #12
yeukhon wrote: post #8

Earlier quoted context omitted.

> "The simplest hack is to use a configuration management tool" > "You can also use a credential management suite for a more robust solution" You have to start somewhere, this is why automated system with credentials isn't a simple task to solve. Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you ne…

I don't think it's quite as complicated as you make it out to be. 1. Write a script that will, when given a specific key, will decrypt a file, extract a specific credential that matches the key, and return it. (Credential Extractor-Writer) 2. Put the CEW file somewhere the devs don't have access. (Credential Store) 3. Make a script to connect to a specific host and port using PKI or public-key auth (HTTPS, SSH), and…

I am not arguing you can't implement a solution. You literally just repeated what I said by specifying A specific implementation. My point earlier is that you will never be able to keep anything secret. There is always a point of trust you have to give up and hope your extreme defense system doesn't crack / expose.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#15

Post by yeukhon »

dozzie wrote: post #10
yeukhon wrote: post #8

Earlier quoted context omitted.

> "The simplest hack is to use a configuration management tool" > "You can also use a credential management suite for a more robust solution" You have to start somewhere, this is why automated system with credentials isn't a simple task to solve. Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you ne…

>> "The simplest hack is to use a configuration management tool" >> "You can also use a credential management suite for a more robust solution" > Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you need to keep the token somewhere. You see, the problem springs from you mistaking Ansible for configura…

When you said

> "You see, the problem springs from you mistaking Ansible for configuration management tool. It is not, it is somebody's deployment script."

You lost credibility from my PoV. Ansible is capable of doing what Chef can do. Ansible can use dynamic inventory which means Ansible can use dynamic secret infrastructure. That's not the default mode of Ansible out of box, but much like Chef and Puppet, Ansible is made up of somebody's deployment script as well. You and I didn't just write up Puppet out of no where, and there are community plugins available for used, and those plugins are just somebody else's deployment script/component.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#16

Post by chousuke »

dozzie wrote: post #10
yeukhon wrote: post #8

Earlier quoted context omitted.

> "The simplest hack is to use a configuration management tool" > "You can also use a credential management suite for a more robust solution" You have to start somewhere, this is why automated system with credentials isn't a simple task to solve. Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you ne…

>> "The simplest hack is to use a configuration management tool" >> "You can also use a credential management suite for a more robust solution" > Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you need to keep the token somewhere. You see, the problem springs from you mistaking Ansible for configura…

Puppet can do templates just fine in masterless mode. Though nowadays, you should use EPP instead of ERB for robustness (strong typing helps a lot)

Your puppet master can be your credential "database" if you use eg. hiera+eyaml. You still need to secure your puppetmaster, obviously, but since it uses public key crypto, you don't even need to make it possible for developers to decrypt secrets. Master key leaks would still be a problem, though.

There are various caveats when working with sensitive data in Puppet (4.something added the "Sensitive" data type which prevents things from leaking into catalogs) but since puppet clients are authenticated with client certificates, you can control which server should have have access to what data.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#17

Post by dozzie »

yeukhon wrote: post #15
dozzie wrote: post #10

Earlier quoted context omitted.

>> "The simplest hack is to use a configuration management tool" >> "You can also use a credential management suite for a more robust solution" > Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you need to keep the token somewhere. You see, the problem springs from you mistaking Ansible for configura…

When you said > "You see, the problem springs from you mistaking Ansible for configuration management tool. It is not, it is somebody's deployment script." You lost credibility from my PoV. Ansible is capable of doing what Chef can do. Ansible can use dynamic inventory which means Ansible can use dynamic secret infrastructure. That's not the default mode of Ansible out of box, but much like Chef and Puppet, Ansible i…

> Ansible is capable of doing what Chef can do.

So is gawk, except nobody tries to shoehorn it to do so or claim that it's designed for this. Ansible's very architecture and operation model are causing troubles where should be none, like applying configuration changes to hosts that happened to be temporarily down.

> [...] much like Chef and Puppet, Ansible is made up of somebody's deployment script as well.

I don't know the history of Chef, but I assure you that Puppet was never somebody's deployment script that happened to be published and gain traction. It was designed ground up as a configuration management tool, after its author deemed cfengine 2.x too troublesome, which again was a configuration management since its early 2.0 days (and probably since 1.0 version).

Configuration management requires completely different operation mode than deployment; one is asynchronous and unattended, the other is a synchronous list of steps to take and often needs to stop on the first trouble to appear.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#18

Post by joper90 »

hdhzy wrote: post #3
tptacek wrote: post #2

Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.

Just curious - what's the preferred way of passing secrets from the deployment process to the application? Environment variables? Simple to use and understand but can leak to child processes and crash reports. Files on disk? Usually can also be read by children. Via stdin on app startup? Seems simple... Some other way?

Key\Values in consul. Then pass in an env car with the key.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#19

Post by IncRnd »

hdhzy wrote: post #3
tptacek wrote: post #2

Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.

Just curious - what's the preferred way of passing secrets from the deployment process to the application? Environment variables? Simple to use and understand but can leak to child processes and crash reports. Files on disk? Usually can also be read by children. Via stdin on app startup? Seems simple... Some other way?

Those are different implementations of the same thing, the manner of passing secrets. While that sounds like a truism, saying it has value - because the issue isn't passing of secrets but how to protect the secrets before you pass them. In other words, how to leverage external key material that unlocks your secrets.

This change takes the application from security through obscurity to something that uses protected secrets.

Re: Crypto Tools for DevOps: Git-Crypt – Tozny

#20

Post by emmelaich »

tptacek wrote: post #2

Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.

Well, not in your main repo.

But secrets like other config benefit from versioning and so the perfect place to keep them is in a version control system no?

You can sharply limit who has access; and perhaps only allow access via some web api.

For small teams or lone developers I think git-crypt is great.

Post reply on HN