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