From Libvirt Wiki
Jump to: navigation, search

Setting up libvirt for TLS (Encryption & Authentication)

Setting up your virtualisation infrastructure for Transport Layer Security (TLS) isn't very difficult. However, it can be a bit involved for someone not already familiar with the details.

These next pages take you through the four main steps involved with setting up TLS for libvirt, from the high level concepts, through to the exact steps with examples.

You should be able to follow through, adapting the examples directly for your own virtualisation infrastructure.

Full list of steps

  1. TLS Concepts in libvirt - this page
  2. Create the Certificate Authority Certificate
  3. Create the Server Certificates
  4. Create the Client Certificates
  5. Configure the libvirt daemon
  6. Further References

The central concept

At its heart, Transport Layer Security is a way of encrypting communication between two computers. The encryption is done using an approach called PKI, which stands for Public Key Infrastructure.

It is fairly simple in concept, always involving one computer, "the client", establishing a connection with a receiving computer, "the server".

Client to Server communication

TLS uses files called Certificates for this communication, with the client computer starting the connection always having a Client Certificate, and the receiving computer always having a Server Certificate.

The initiator has a Client Certificate, the receiver has a Server Certificate

If you have the situation where two computers need to communicate with each other using TLS, then they both need a Client Certificate and a Server Certificate.

If they both need to communicate with each other, they both need both certificates

This is also the example scenario we'll be using in these pages.

Our example scenario

In our example scenario, we have two virtualisation host servers. The first, Host System 1, is named host1. The second, Host System 2, is named host2.

host1 and host2

In our example environment, these host servers will occasionally need to communicate with each other. For example, when moving a virtualised guest from host1 to host2, or vice versa. For this to work, they both need their own Client Certificate, and Server Certificate.

host1 and host2 with both Client and Server certificates

In our example scenario, we also have an administrative desktop used to manage the virtualisation hosts. With it we can connect to either of the virtualisation hosts and perform administrative functions like creating new guests, moving guests between the hosts, and reconfiguring or deleting guests.

This administrative desktop is named admindesktop. It will exclusively connect to the virtualisation hosts, never receiving new connections from them. This means it only needs a Client Certificate, and does not need it's own Server Certificate.

administration workstation establishes communication to both servers

Private Key files

Part of the PKI approach used in TLS, means that for every Certificate file a computer wants to use fully, it must also have a matching Private Key file.

Tls concepts host1 with both certs and keys.png

Private Key files are critically important, and must be kept very secure. They allow any computer with a matching certificate to represent itself as what is in the certificate.

For example, Host System 1 has both Client and Server Certificates. These certificates contain information stating they are for the system host1.

Because only Host System 1 has the private key files for these certificates, it is the only one that can say "I am host1".

If an unauthorised person was to obtain one of these key files, they could make their own certificates claiming one of their systems is host1 instead. This could potentially give them access to your virtualisation servers, which is not what you want.

Signing other Certificates

Possessing both a Certificate and its Private Key also gives an additional benefit, being able to sign other Certificates. This adds a small, cryptographically secure piece of information to the certificate file being signed, indicating it is authentic.

This is important, because it allows us to establish a web of trust, where we have all of our certificates signed either by each other, or by a central certificate we know to be good.

Certificate Authority

This approach, of having a central certificate to sign many others is regarded as good security practice. It also allows for reasonably simple certificate management when compared to other alternatives, and is the approach used in libvirt.

This central Certificate is referred to as a Certificate Authority Certificate. We create one in the very first step of our TLS set up on the next page, then use it for signing every Client and Server Certificate we create.

Tls concepts ca cert signs other certs.png

Full list of steps

  1. TLS Concepts in libvirt - this page
  2. Create the Certificate Authority Certificate
  3. Create the Server Certificates
  4. Create the Client Certificates
  5. Configure the libvirt daemon
  6. Further References