Jump to: navigation, search


Public Key Infrastructure For Openstack


While it is possible to address using a Public Key Infrastructure (PKI) approach solely within the context of Keystone, the security of the overall OpenStack system would not appreciably increase. Thus, this blueprint describes an overall PKI approach for securing an OpenStack deployment.

Authentication in OpenStack is a two part mechanism. The first stage is when the user makes the initial authentication to Keystone, which results in the issue of a token. The second is the use of the token to provide single sign on and delegated authentication throughout the OpenStack cluster. PKI can improve the security of the first stage. It can both help security and scalability of the second.

There is only one Cryptographically secure means of authentication a web connection that can be performed over the standard ports used for HTTP and HTTPS. This is X509 certificate based authentication. SSL connections already require X509 certificates from the server side to establish the connection. Extending the requirement to X509 for client based authentication is a logical step.

Note that while Kerberos is Cryptographically secure, but requires IP ports other than 80 and 443. These are routinely blocked by firewalls. Work is underway to address this as part of the HTTP/Kerberos specification, and will likely be an alternative solution for future versions of OpenStack. One technology worth tracking is IAKERB support


The Eventlet Web Server must support client certificate based authentication. Here is the relevant RFC. Alternatively, Keystone must be deployed in Apache HTTPD.

The OpenStack deployment must have access to a Certificate Authority. This does not have to be one of the signed CAs already present in the browser, nor does it need to be signed by one of them, as alternative methods of CA certificate distribution may suffice based on the OpenStack implementing organizations capabilities.

Initial Authentication

When a user is created in Keystone, they will be given a one-time-password that they will then use to establish a key-pair. Only the Public Key will be stored on the Keystone server, the Private key will only be stored on the end users system. The public key will be signed by the certificate authority (X509) and then stored in the Keystone system. From this point on, when authenticating to Keystone, the user will use the client certificate.

Once a user provisions a certificate to a machine it is hard to move it to a another machine you have at your disposal: It is possible, but the user needs to have access to the original machine and perform some pretty specific operations. We can provide documentation for users that wish to do this.

Additional Systems

However, a user can safely have multiple private keys without providing too much overhead in the system. They would need a way to indicate that a new machine is being provisioned. A possible approach that has high over head but high security is:

1. From a machine that has a cert, generate a new One Time Password (OTP) for the new machine 2. From the new machine, use the OTP to fetch a certificate 3. From the original machine, approve the new machine.

An second mechanism using the same sort of confirmations done for lost passwords could be used to confirm the Private key from new machine.

For a third mechanism, an administrative user could also provision a OTP for enrolling a new machine.

Delegation and Scaling

This mechanism has been written up in more detail: http://adam.younglogic.com/2012/05/signed-authz-authn/

The following is an explanation of a delegated authorization scheme. The format of the signed document is the "Cryptographic Message Syntax" as described in http://tools.ietf.org/html/rfc5652

The current token architecture in Keystone requires the active participation of the Keystone server to assure that a token is valid for a user/tenant. With public/private key pairs, this assurance is performed without a network call.

If the token contains just the following data :

  • {username: admiyo,tenant: Fedora,expires: 2359:05May2012, roles: [admin,editor]}

This message is then encrypted with Keystones private key. Any service that has Keystones public key can decrypt the message. Since it is decrypted with the public key, it had to be encrypted by Keystone, and is therefore valid. The Keystone Certificate only has to be distributed once to each service, and can be fetched on demand.

This is an in-place replacement for the existing Token scheme. The CMS document can function as the value for the x-auth-token header without any changes on the services. However, modification of th auth_token middleware to be CMS based tokens will allow the the servive to avoid the network call back to Keystone in order to verify the validity of the token as well as the roles that the user has in the tenancy.

By themselves, X509 client certificates provide a single sign on solution that uses a variation of the above approach. However, they do not provide a means of delegating authority. Signing a message requires a private key, and the users private key is maintained outside the Keystone system. The browser does not currently have a mechanism to allow signing of a message on behalf of a website. Delegation of authorization is required by the Horizon Dashboard in order to perform operations in behalf of the logged in user. The token mechanism described here will allow for delegation of authority inside of an OpenStack deployment.

Each Keystone server in a deployment will have a Key pair and a published X509 certificate distributed to the other services in the OpenStack cluster. Keystone will continue to distribute authentication tokens the same way that it does now, but they will become X509 Certificates signed by the Keystone servers private key. This way, each of the end servers will be able to check the validity of a token without calling back to the Keystone server. While a user will be able to authenticate to the WebUI Horizon Dashboard with their Client certificate, they will still need to use the Keystone token to be able to delegate authority from Horizon to the other OpenStack services in the cluster. The tokens will have the UserID of the user embedded in them. The tokens will have embedded in them a time-to-live value, which will default to a duration of 8 hours. These tokens can be used in an automated fashion without explicit user interaction. If certain operations require longer delegation tokens, they will require explicit user authorization.


Dogtag PKI is the current best option for a Certificate Authority as well as other aspects of the PKI. It is a full PKI implementation, is completely Open Source, and is built on top of Network Security Services (NSS) the Only Opensource Cryptography library that has been approved for use with the US Government, as it meets both Common Criteria and Federal Information Processing Standard (FIPS) 140-1. In addition, the Dogtag PKI is currently building a REST interface into the server that will work in well with the rest of the Openstack components and development approach.