The PKI version of the Keystone tokens use a standard format for cryptographic signing of documents. Crypto Message Syntax (CMS) is the mechanism behind S/MIME and is well supported by the major cryptographic libraries: OpenSSL and NSS both have well documented CMS support. Messaging in OpenStack requires guaranteed identification of the author.

The publish-subscribe integration pattern allows one process to produce messages and multiple to consume them. More complex patterns build on this idea to allow linking multiple producers with multiple consumers. Dynamic Message Routing has many specific variations such as the process manager pattern which have been implemented inside of Open Stack.

Dynamic Router

Lets take the case where a compute node needs to contact a scheduler, any scheduler. The scheduler needs to know which compute node has contacted it. If a hypervisor exploit compromises a compute node, and the messages are not signed, that compute node can impersonate and other compute node in the group. If, on the other hand, messages from the compute node to the scheduler topic are signed, the scheduler can confirm that the message producer is the hypervisor in question.

Message Envelope Wrapper Pattern

Note that not every piece of the Message should be signed by the same entity. The Routing Slip Pattern provides for multiple entities to process a message. Each needs to indicate that they have seen it. Thus, “checking off” the slip means adding a cryptographic signature, most likely of the Fingerprint of the message.

Routing Table or Routing Slip Pattern

The CMS format allows the signer to embed the certificates in the signed message. The benefit is that that message is self contained, assuming that you have a trusted the CA certificate. The downside is that the certificate data greatly increases the message size. Even compression does not completely remove this shortcoming. In the first PKI implementation, this added data of the certificate was not required, as we know exactly who is signing the certificate. However, in the future, we want to be able to have multiple Keystone servers signing certificates. There is a field inside the CMS document that indicates the signer. This value can be extracted and uswd to determine the signer of the certificate, and thus used to select the certificate used for signature validation.

All CMS can tell us is whether the signature of a document is valid. It does not tell us if the signer had authority to sign that document. Some portion of the document has to be compared with the identity of the certificate owner to confirm authorization to sign. In the case of our computer node posting to the scheduler topic, the consumer would want to confirm the signature of the request, and then confirm that the node ID of the request matches the node id of the certificate holder.

Directory

It is this last problem that points to a missing piece in Open Stack: a centralized registry for undercloud entities. Keystone does not have this view of the undercloud, at most it knows about endpoints. But the majority of the hosts in the undercloud are driven by the message queue, and are not HTTP endpoints. Keystone has no way to uniquely identify them.

There are several efforts that are converging on a solution.  The Recent Key Distribution Server (KDS) extension to Keystone provides for a unique identifier for the sharing of symmetric keys.

Kerberos

In more traditional datacenter management approaches, hosts can be registered in LDAP and identified via Kerberos principals.

Zookeeper

The Zookeeper project provides a comparable mechanism for tracking the hosts enrolled in complex workflows.

Regardless of the mechanism, the base requirement is to provide a contextual mapping from the X509 certificate for the public key used to validate the signature to the OpenStack entity that signed the document.

A scalable system based on X509 and PKI requires a certificate authority. It does not have certificate signed by one of the public CAs such as you would find pre-populated in your browsers certificate database. It merely needs to be established a-priori as part of the OpenStack infrastructure, with a secure mechanism for distributing the CA certificate itself.

The actual mechanism to perform the signing and verification would mirror that used for the tokens, as I talked about here.