Juno Updates – Security

Written by Nathan Kinder

There is a lot of development work going on in Juno in security related areas. I thought it would be useful to summarize what I consider to be some of the more notable efforts that are under way in the projects I follow.

Keystone

Nearly everyone I talk with who is using Keystone in anger is integrating it with an existing identity store such as an LDAP server. Using the SQL identity backend is really a poor identity management solution, as it only supports basic password authentication, there is lack of password policy support, and the user management capabilities are fairly limited. Configuring Keystone to use an existing identity store has it’s challenges, but some of the changes in Juno should make this easier. In Icehouse and earlier, Keystone can only use one single identity backend. This means that all regular users and service users must exist in the same identity backend. In many real-world scenarios, the LDAP server used for users and credentials is considered to be read-only by anything other than the normal user provisioning tools. A common problem is that the OpenStack service users are not wanted in the LDAP server. In Juno, it will be possible to configure Keystone to use multiple identity backends. This will allow a deployment to use an LDAP server for normal users and the SQL backend for service users. In addition, this should allow multiple LDAP servers to be used by a single Keystone instance when using Keystone Domains (which previously only worked with the SQL identity backend).

I mentioned above that Keystone’s SQL identity backend is not ideal. In many ways, Keystone’s LDAP identity backend is also not ideal. Authentication is currently limited to using the LDAP simple bind operation, which requires users to send their clear-text password to Keystone, which is then sent to the LDAP server (hopefully all over SSL/TLS protected connections). Keystone already allows for stronger authentication via external authentication, but there are some barriers to adoption that should be eliminated in Juno. Using external authentication requires that Keystone is run in Apache httpd. Unfortunately, the size of Keystone’s PKI formatted tokens can easily get large enough to cause problems with the httpd/mod_wsgi interaction due to the amount of service catalog information contained within the token. In Juno, the default token format is a compressed PKI format called PKIZ. This significantly reduces the size of tokens such that running Keystone in httpd is feasible. This will make it possible for Keystone deployments to leverage a number of httpd modules that allow for strong forms of authentication such as Kerberos and X.509 client-certificates. The Keystone team even switched all of it’s gate jobs to use httpd recently, as it is considered to be the recommended deployment method going forward.

Keystone has an existing Federation extension that allows one to define mappings to translate SAML assertions into Keystone role assignments. In Juno, this mapping functionality is being made more general purpose to allow it to be used with external authentication via Apache httpd modules. This will allow for some very interesting use-cases, such as having Apache provide all of the user and group information necessary to figure out role assignment without the need for Keystone to maintain it’s own identity store. For example, one should be able to use httpd with mod_lookup_identity to allow SSSD on the underlying platform to provide Keystone with all of the user and group information from an external backend identity provider (FreeIPA, Active Directory). This offloads all of the LDAP complexity to SSSD, which provides LDAP connection pooling and caching to allow for continued service even if the LDAP server is down. Combined with strong authentication like Kerberos, this offers a performant and secure approach to authentication and identity while leaving Keystone to focus on it’s main task of authorization within OpenStack.

Barbican

The Barbican project looks to be progressing nicely through the incubation process. Barbican was initially designed with a plug-in model, with a single hardware security module plug-in. There has been quite a bit of interest in implementing various new plug-ins, which has highlighted the need to re-architect the plug-in interface to allow for multiple plug-in types. This re-architecture has has been one of the big focus items of the Juno cycle thus far, as it affects any new functionality that is being implemented as a plug-in.

A plug-in was implemented to allow the Dogtag PKI DRM (data recovery manager) subsystem to be used for key generation and storage. This should allow for easy integration for those with existing Dogtag installations as well as being an attractive well-proven key archival and recovery solution for new deployments.

Barbican is expanding it’s functionality to allow for more than it’s initial use-case of storing (and optionally generating) symmetric keys. The ability to store asymmetric key pairs and certificates is being added as well in Juno, which is of particular interest for things like LBSaaS. The ability to act as an interface for handing certificate requests and interacting with a CA (certificate authority) are also being worked on, with plug-ins for Dogtag and Symantec CAs.

Kite

The Kite project continues to work it’s way through implementation, albeit slowly. There has only been one developer working part-time on the implementation, so it’s not likely to be in a usable state until the Kilo release. The good news is that an additional contributor has recently stared contributing to this effort, working from the Oslo messaging library side of things. Hopefully this speeds things along so that Kite is available for other projects to start developing against early in the Kilo cycle.

Cross-Project

A new Session object has been added to Keystoneclient for use by the client code in other projects. The Session object centralizes the responsibility of authentication and transport handling. From a security standpoint, this is very nice since it centralizes all of the HTTPS client-side code across all projects as opposed to the current situation of having many different implementations. The configuration of things like certificate validation will also be consistent across all projects once they utilize the Session object, which is a particular item that is a bit of a mess in Icehouse and earlier releases. Nova has already been converted to use the new Session object, and conversion of the Cinder and Neutron projects is in progress.

There has been some work in Devstack that is worth noting, even though it’s code doesn’t directly affect actual deployments. Patches have been proposed to allow Devstack to easily be set up with SSL/TLS support for many of the main services. The goal of this work is to allow SSL/TLS to eventually be regularly tested as a part of the continuous integration gate jobs. This is an area that is not currently well tested, even though it is crucial functionality for secure deployments. This work should result in more robust SSL/TLS code, which benefits everyone.