On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trma?? wrote:
> This patch adds a "secret" as a separately managed object, using a
> special-purpose API to transfer the secret values between nodes and
> libvirt users.
>
> Rather than add explicit accessors for attributes of secrets, and
> hard-code the "secrets are related to storage volumes" association in
> the API, the API uses XML to manipulate the association as well as
> other attributes, similarly to other areas of libvirt.
>
> The user can set attributes of the secret using XML, e.g.
> <secret ephemeral='no' private='yes'>
> <uuid>b8eecf55-798e-4db7-b2dd-025b0cf08a36</uuid>
> <volume>/var/lib/libvirt/images/mail.img</volume>
> <description>LUKS passphrase for our mail server</description>
> </secret>
> If <uuid/> is not specified, it is chosen automatically.
>
> The secret value can be either generated and stored by libvirt during
> volume creation, or supplied by the user using virSecretSetValue().
>
> A simple API is provided for enumeration of all secrets. Very large
> deployments will manage secret IDs automatically, so it is probably not
> necessary to provide a specialized lookup function (allowing the volume
> key -> secret ID lookup in less than O(number of secrets)). These
> functions can eventually be added later.
If the guest XML contains the UUID of the secret, we already have
O(1) lookup based on UUID. Adding a lookup based on volume could
be convenient later, but not critical.
>
> Changes since the second submission:
> - Changed API to revolve around a virSecretPtr. The operations are now:
> virSecretGetConnect
> virConnectNumOfSecrets
> virConnectListSecrets
> virSecretLookupByUUIDString
> virSecretDefineXML
> virSecretGetUUIDString
> virSecretGetXMLDesc
> virSecretSetValue
> virSecretGetValue
> virSecretUndefine
> virSecretRef
> virSecretFree
So just to enumerate some of the scenarios we're trying to address:
- Auto-created secrets for qcow2 using local DB
1. App calls virStorageVolCreateXML() to create the qcow2 volume
requesting encryption with auto-created secret
2. Libvirt generates a random passphrase, and internally creates
a secret and sets its value to the passphrase, and stores it
in the local DB
3. App defines guest config with virDomainDefineXML()
4. App boots the guest with virDomainCreate()
5. libvirt automatically fetches key out of its local DB
- Auto-created secrets for qcow2 with no local DB storage
1. App calls virStorageVolCreateXML() to create the qcow2 volume
requesting encryption with auto-created secret
2. Libvirt generates a random passphrase, and internally creates
a secret and sets its value to the passphrase, and stores it
in the local DB
3. App defines guest config with virDomainDefineXML()
4. App boots the guest with virDomainCreate()
5. libvirt automatically fetches key out of memory
6. App fetches auto-generated passphrase with virSecretGetValue
and saves it somewhere safe
- Manually specified passphrases with no local DB storage
1. App calls virSecretDefineXML to create a secret, ephemeral set
2. App calls virSecretSetValue() to set the passphrase
3. App calls virStorageVolCreateXML() to create the qcow2 volume
requesting encryption
4. App defines guest config with virDomainDefineXML()
5. App boots the guest with virDomainCreate()
6. libvirt automatically fetches key from memory
- External off-node keystore with cluster of hosts, starting a guest
1. App calls virSecretDefineXML to create a secret for the
VM to be deployed
2. App calls virSecretSetValue() to set passphrase
3. App calls virDomainCreateXML to create a transient guest
4. App calls virSecretUndefine to remove the secret
- External off-node keystore with cluster of hosts, creating a volume
1. App calls virSecretDefineXML to create a secret for the
VM to be deployed
2. App calls virSecretSetValue() to set passphrase
3. App calls virStorageVolCreateXML to create a volume
4. App calls virSecretUndefine to remove the secret
I could go on with other various scenarios, bt I think the API we have
allows for all the cases we care about, both external 3rd party keystore
and a local libvirt managed one.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list