On Sat, Dec 15, 2012 at 3:55 PM, John Kinsella <j...@stratosec.co> wrote:
> Good point, there…maybe what we need here is to beef up the password server
> idea to provide a standardized conduit to get info down to a VM. Similar to
> EC2's user-data.
>
> Data I could see this framework providing:
> * System passwords
> * Additional IPs (so need to be able to return data sets, JSON-style maybe?)
> * Encryption keys
> * Metadata about the VM ("webserver," "database," "high-availability,"
> "master")
> * What else?
>
> One very important piece that's missing is a timeout - need to be able to
> have the object server provide the object(s) when a VM boots, but should be
> able to specify for some objects that after X seconds that data should be
> thrown away. Hugely important for encryption keys (I want to provide key to
> decryption system at boot, but don't want malicious user to be able to login
> a week later and easily get that key).
>
> So I'd suggest maybe have one spec to update/expand the password server to be
> an object server, and then Jayapal's multiple-IP spec would integrate with
> that.
>
> Super awesome bonus points: support for fetching/storing said objects in HSM.
> I've got one vendor in mind who has a sw solution we're looking at, but
> following a PKCS#11 format would probably be best.
In that vein - I'd prefer seeing us do a better job of making
cloud-init something usable with CloudStack.
I know there is essentially cloud-init support here:
https://code.launchpad.net/~lcosmin/cloud-init/cloudstack
