5:42 p.m.
Hello,
----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Fri, Jul 24, 2009 at 07:25:54AM -0400, Miloslav Trmac wrote:
> A client in this case is the central, fully trusted, management
> system (e.g. oVirt), there is no need to protect against it.
> A more likely flow is
>
> MGMT client (no knowledge of secrets)
> |
> v
> MGMT server + key server (integrated or separate but cooperating)
> |
> v
> libvirt daemon
> |
> v
> qemu
>
> > What I am suggesting is that libvirt daemon should communicate
> > with the key server directly in all cases, and take the client
> > out of the loop. The client should merely indicate whether it
> > wants encryption or not, and never be able to directly access
> > any key material itself. With a direct trust relationship
> > between the key server and each libvirtd daemon, you do now
> > have a guarentee that keys are only ever used on the node for
> > which they are intended. You also have the additional guarentee
> > that no libvirt client can ever see any key secrets or passphrases
> > since it has been taken completely out of the loop.
>
> As far as I understand it, the whole point of virtual machine
> encryption is that the nodes are _not_ trusted, and different
> encryption keys protect data on different nodes.
I did not mean to imply that libvirtd on a node should have
access to *all* secrets. Each libvirtd daemon has its own
identity, and when talking to a keys server it would authenticate
and the key server would only allow it access to some sub-set
of keys. ie, only the keys neccessary for VMs it needs to run.
<snip>
If you have each libvirtd requesting secrets directly from the
keystore, at the time it starts a guest, then should an admin
issue a migrate command manually, the destination libvirtd
would still be unable to access the secrets of the incoming
VM, since the keystore will not have been configured to allow
it access.
We also have to bear in mind how the MGMT server communicates
with the libvirt daemon. One likely option is using a messaging
service, which offers authenticity but not secrecy. ie, libvirt
receiving a request off the message bus can be sure the request
came from the mgmtm server, but cannot be sure it wasn't seen
by other users during transport. Thus by including secrets in
the XML, you could be exposing them to the message bus adminstrator.
Is this likely to happen? No such transport is currently implemented AFAICS, and just
using TLS is much simpler - it is already implemented, and gives you authentication of
both sides almost for free. Why would such a messaging service be necessary for the
client<->libvirtd connection, but not the libvirtd<->key server connection?
Taking your diagram, I think I would generalize it still further
to allow for mgmt server to be optional separate from key server,
and to introduce a "message bus" between MGMT server & libvirt.
Really pushing the limits of ASCII art...
MGMT client
|
V
MGMT server <---> Key server
| ^
V |
message bus |
| |
V |
libvirt daemon <----/
|
V
QEMU
This makes sense if you do not want to store any secrets locally at the node at any cost,
but the strong coupling of the libvirtd daemon and the key server is a significant
disadvantage: not only would the key server and libvirtd both have to implement the same
protocol for transferring secrets, but the MGMT server, key server and libvirtd would all
have to share the same concept of "identity" and the same method of
authentication - and the MGMT server would have to manipulate the libvirt accounts on the
key server.
There are a few products that offer a company-wide key server, but there AFAIK is no
standardized protocol for transferring the secrets yet (the KMIP committee was formed only
a few months ago), and not even a proposal for any account management on the key server.
We don't know what the industry standard will look like - or whether there will be
any; right now, any key server used in connection with libvirt-managed nodes would have to
implement a libvirt-specified interface (in addition to any interface it may provide to
other clients).
It is much simpler to use the already implemented libvirt remote interface, and give the
MGMT server implementors a free hand in deciding which key server, if any, they will use,
and to avoid the non-trivial effort of specifying the specialized libvirtd<->key
server protocol and implementing both ends of it.
If secrets related to auto-start domains are stored locally on the node, all secrets
needed by libvirtd will be anticipated by the MGMT server, who can provide them before
starting the operation. This makes the libvirtd->key server connection unnecessary.
The API proposal that will follow adds a secret management interface to libvirtd. The API
allows libvirtd to use a persistent local secret store, as well as an external key server
as described above. In addition, it also allows a "fully managed" mode, where
the storage and provision of secrets is the responsibility of the MGMT server. This is
accomplished by giving each secret two attributes: "private", which prohibits
libvirtd from divulging the secret to any client (this was done in the previous
implementation in XML, but now that secrets are out-of-bound, making secrets private does
not break any round-trip XML editing), and "ephemeral", which prohibits libvirt
from storing the secret persistently. The MGMT server would send the necessary secrets
before any operation that needs them, and delete them from the node when they are no
longer necessary.
Looking at your use cases:
- A node can only see secrets for VMs it is configured to run
Same in "fully managed" mode.
- MGMT server does not need to ever see the secrets itself. It
merely controls access for which nodes can see them, and can
request generation of new secrets
The MGMT server needs to see the secrets in
"fully managed mode". The MGMT server can actually see them even if libvirtd
talks to the key server directly, because the key server is allowed to manipulate
permissions of the secrets and it can give itself the permission to read them. The MGMT
server can also delete any interface, or boot a "rescue image" that copies the
plaintext out of the virtual machine. The MGMT server must be trusted in any case.
- Messages between the MGMT server & libvirtd do not need to
be encrypted, since they don't include secrets
I can't see why this is
useful - the connection will use TLS anyway.
- Other users who authenticate to libvirt on a node cannot
move a VM to an unauthorized node, since it can't see secrets
Same in
"fully managed" mode.
- VM save memory images (which include the fully XML) do not ever
expose the secrets. So VM save image cannot be restored on an
unauthorized node.
Same in "fully managed" mode.
Mirek