Storing and distributing secrets.

12 September 2014 21:50

I run a number of hosts, and they are controlled via a server automation tool I wrote called slaughter [Documentation].

The policies I use to control my hosts are public and I don't want to make them private because they server as good examples.

Because the roles are public I don't want to embed passwords in them, which means I need something to hold secrets securely. In my case secrets are things like plaintext-passwords. I want those secrets to be secure and unavailable from untrusted hosts.

The simplest solution I could think of was an IP-address based ACL and a simple webserver. A client requests something like:

http://secret.example.com/user-passwords

That returns a JSON object, if the requesting host is permitted to read the data. Otherwise it returns a HTTP 403 error.

The layout is very simple:

|-- secrets
|   |-- 206.190.139.148
|   |   `-- auth.json
|   |-- 127.0.0.1
|   |   `-- example.json
|   `-- 80.68.84.109
|       `-- chat.json

Each piece of data is beneath a directory/symlink which controls the read-only access. If the request comes in from the suitable IP it is granted, if not it is denied.

For example a failing case:

skx@desktop ~ $ curl  http://sss.steve.org.uk/chat
missing/permission denied

A working case :

root@chat ~ # curl  http://sss.steve.org.uk/chat
{ "steve": "haha", "bot": "notreally" }

(The JSON suffix is added automatically.)

It is hardly rocket-science, but I couldn't find anything else packaged neatly for this - only things like auth/secstore and factotum. So I'll share if it is useful.

Simple Secret Sharing, or Steve's secret storage.

Tags: passwords, secrets | 5 comments

Comments on this entry

Ben Kibbey at 22:01 on 12 September 2014
http://bjk.sf.net

You may want to give pwmd a try (http://pwmd.sf.net).

Steve Kemp at 22:11 on 12 September 2014
http://steve.org.uk/.

That does look interesting, thank you for the pointer.

Joey Hess at 22:26 on 12 September 2014
http://joeyh.name/

Color me doubtful about relying on IP addresses. Also, no transport encryption?

I dealt with the same need in propellor using a gpg-encrypted file of secrets. The secrets that a given host needs are determined by introspecting over the host's config, and are extracted and sent to it over a ssh connection.

Steve Kemp at 04:55 on 13 September 2014

I did think about requiring a POST request instead of a GET and sending a shared key, or similar, but then decided that if I wasn't going to use GPG then it was a bit pointless.

As for transport, I'd assume any real world deployment would use SSL, but that's not present on my sample host.

Slaughter can't use SSH like that, since it doesn't maintain any link to the policy-server, it could pull down encrypted files and decrypt locally, but then I'd have a problem of key-distribution I'd rather avoid.

Why not making permanent reverse ssh connections (autossh) between hosts and secretkeeper created from the secret keeper?
So you don't need to distribute key to the hosts ... only public key of the secretkeeper.
Only an idea ;-)

Storing and distributing secrets.

Comments on this entry

Recent Posts