Barbican is a REST API designed for the secure storage, provisioning and management of secrets such as passwords, encryption keys and X.509 certificates. It is aimed at being useful for all environments, including large ephemeral clouds.

Barbican is integrated with several OpenStack features, either directly or as a back end of Castellan.

Barbican is often used as a key management system to enable use cases such as Image signature verification, Volume encryption. These use cases are outlined in the Use Cases

Barbican Role Based Access Control


Secret store back ends

The Key Manager service has a plugin architecture that allows the deployer to store secrets in one or more secret stores. Secret stores can be software-based, such as a software token, or hardware devices such as a hardware security module (HSM). This section describes the plugins that are currently available and discusses the security posture of each one. Plugins are enabled and configured with settings in the /etc/barbican/barbican.conf configuration file.

There are two types of plugins: crypto plugins and secret store plugins.

Crypto plugins

Crypto plugins store secrets as encrypted blobs within the Barbican database. The plugin is invoked to encrypt the secret on secret storage, and decrypt the secret on secret retrieval. There are two flavors of storage plugins currently available: the Simple Crypto plugin and the PKCS#11 crypto plugin.

Simple crypto plugin

The simple crypto plugin is configured by default in barbican.conf. This plugin uses single symmetric key (KEK - or ‘Key Encryption Key’) which is stored in plain text in the barbican.conf file to encrypt and decrypt all secrets. This plugin is considered a less secure option and is only suitable for development and testing as the master key is stored within a config file in plain text, and is therefore not recommended for use in production deployments.

PKCS#11 crypto plugin

The PKCS#11 crypto plugin can be used to interface with a Hardware Security Module (HSM) using the PKCS#11 protocol. Secrets are encrypted (and decrypted on retrieval) by a project specific Key Encryption Key (KEK) which resides in the HSM. Since a different KEK is used for each project, and since the KEKs are stored inside an HSM (instead of in plaintext in the configuration file) the PKCS#11 plugin is much more secure than the simple crypto plugin. It is the most popular back end amongst Barbican deployments.

Secret store plugins

Secret store plugins interface with secure storage systems to store the secrets within those systems. There are two types of secret store plugins: the KMIP plugin and the Dogtag plugin.

KMIP plugin

The Key Management Interoperability Protocol (KMIP) secret store plugin is used to communicate with a KMIP-enabled device, such as a Hardware Security Module (HSM). The secret is securely stored in the KMIP-enabled device directly, rather than in the Barbican database. The Barbican database maintains a reference to the secret’s location for later retrieval. The plugin can be configured to authenticate to the KMIP-enabled device using either a username and password, or using a client certificate. This information is stored in the Barbican configuration file.

Dogtag plugin

The Dogtag secret store plugin is used to communicate with Dogtag. Dogtag is the upstream project corresponding to the Red Hat Certificate System, a Common Criteria/FIPS certified PKI solution that contains a Certificate Manager (CA) and a Key Recovery Authority (KRA) which is use to securely store secrets. The KRA stores secrets as encrypted blobs in its internal database, with the master encryption keys being stored either in a software-based NSS security database, or in a Hardware Security Module (HSM). The software-based NSS database configuration provides a secure option for deployments that do not wish to use a HSM. The KRA is a component of FreeIPA, therefore it is possible to configure the plugin with a FreeIPA server. More detailed instructions on how to set up Barbican with FreeIPA are provided in the following blog post.

Threat analysis

The Barbican team worked with the OpenStack Security Project to perform a security review of a best practise Barbican deployment. The objective of the security review is to identify weaknesses and defects in the design and architecture of services, and propose controls or fixes to resolve these issues.

The Barbican threat analysis identified eight security findings and two recommendations to improve the security of a barbican deployment. These results can be reviewed in the security analysis repo., along with the Barbican architecture diagram and architecture description page.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.