Storing and distributing secrets.

Friday, 12 September 2014

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:


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
|   |--
|   |   `-- auth.json
|   |--
|   |   `-- example.json
|   `--
|       `-- 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
missing/permission denied

A working case :

root@chat ~ # curl
{ "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.



Comments On This Entry

[gravitar] Ben Kibbey

Submitted at 22:01:00 on 12 september 2014

You may want to give pwmd a try (

[author] Steve Kemp

Submitted at 22:11:30 on 12 september 2014

That does look interesting, thank you for the pointer.

[gravitar] Joey Hess

Submitted at 22:26:52 on 12 september 2014

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.

[author] Steve Kemp

Submitted at 04:55:26 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.

[gravitar] Sébastien (Auroch) BOLLINGH

Submitted at 05:28:32 on 13 september 2014

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 ;-)


Comments are closed on posts which are more than ten days old.

Recent Posts

Recent Tags