- 1 Project Codename
- 2 Trademarks
- 3 Summary
- 4 Mission Statement
- 5 Detailed Description
- 6 Scope
- 7 Roadmap
- 8 Project Resources
- 9 Team
- 10 Infrastructure Requirements
- 11 Tasks for Incubation (Barbican was incubated on March 10, 2014)
There are no other parts of the Barbican project that will be part of OpenStack.
Barbican is a ReST API designed for the secure storage, provisioning and management of secrets. It is aimed at being useful for all environments, including large ephemeral Clouds.
To produce an OpenStack key management API that simplifies the creation, management and use of keying material for encryption purposes. We plan to achieve this by creating and maintaining a Python service, libraries and documentation as well as working with other OpenStack projects to enable encryption features for their customers and internal infrastructure.
The current state of key management is atrocious. While Windows does have some decent options through the use of the Data Protection API (DPAPI) and Active Directory, Linux lacks a cohesive story around how to manage keys for application use.
Barbican was designed to solve this problem. The system was motivated by internal Rackspace needs, requirements from OpenStack and a realization that the current state of the art could use some help.
Barbican will handle many types of secrets, including:
- Symmetric Keys - Used to perform reversible encryption of data at rest, typically using the AES algorithm set. This type of key is required to enable features like encrypted Swift containers and Cinder volumes, encrypted Cloud Backups, Message Signing, etc.
- Asymmetric Keys - Asymmetric key pairs (sometimes referred to as public / private keys) are used in many scenarios where communication between untrusted parties is desired. The most common case is with SSL/TLS certificates, but also is used in solutions like SSH keys, S/MIME (mail) encryption and digital signatures.
- Raw Secrets - Barbican stores secrets as a base64 encoded block of data (encrypted, naturally). Clients can use the API to store any secrets in any format they desire. The Postern agent is capable of presenting these secrets in various formats to ease integration.
For the symmetric and asymmetric key types, Barbican supports full lifecycle management including provisioning, expiration, reporting, etc. A plugin system allows for multiple certificate authority support (including public and private CAs).
Barbican plans to address issues related to the key management process. This includes key generation, lifecycle management and revocation as well as ancillary services like auditing, logging and compliance concerns. We plan to support a variety of key types include symmetric keys (e.g. AES) and various asymmetric keys including RSA / DSA / ECC keys for use with SSL/TLS, SSH and signing. Additionally, Barbican provides pluggable interfaces to use specialized Hardware Security Modules (HSMs) to provide additional security and compliance as well as a strong source of randomness.
The Barbican project will produce two deliverables:
- barbican - Python ReST API for performing key management
- python-barbicanclient - A python library providing access to features of the Barbican API
Barbican has been participating in the OpenStack release toolchain for the Havana cycle. Our blueprints and milestones can be seen in Launchpad. As a result, we have completed our MVP set of functionality which is detailed below along with our future plans.
In the long term, we see most OpenStack services depending on Barbican to deliver encryption services. In addition, we see customers of an OpenStack cloud also relying directly on Barbican for secret provisioning and storage. We see potential integrations in the following areas:
- Encryption at Rest: Nova, Cinder, Trove, Ironic, Glance, Swift, Marconi, Savannah
- Key Distribution / Management: Nova, Keystone, Neutron, Heat
- Signing / Data Verification: Oslo, Marconi
- Encryption in Flight: Any systems that use SSL, but especially systems that spin resources that need transport protection like Trove or Savannah
These features are all complete.
- API support for CRUD of secrets
- API support for certificate / key creation requests (orders)
- Chef infrastructure for configuration management
- RBAC support
- Crypto plugin model for Hardware Security Module (HSM) support
- 'Dev' plugin for a crypto backend (in place of HSM)
- python-barbicanclient python library
- keep command line client (part of python-barbicanclient)
- Support for transparent encryption for Cinder volumes
- KIMP backend support (based on a third-party library contribution)
- KDS service for message signing
- Support for provisioning SSL/TLS certificates from public CAs (plugin based, Symantec CAs first)
- Support API for certmonger tool
- Backend support for Dogtag (based on third party contributions)
- Support for object encryption in swift (third party contributions)
- Provisioning SSL/TLS from internal CAs
- Support for the Microsoft CA infrastructure
- Support for DEK storage in HSM
- Advanced auditing, logging and reporting
- Compliance with various regimes including PCI, HIPAA, SOX, etc. Possibly FIPS / FISMA
- Server Source Code: https://github.com/stackforge/barbican
- Client Source Code: https://github.com/cloudkeep/python-barbicanclient
- Language: Python
- License: Apache 2.0
The following are the team members currently working on Barbican. In addition to this list, the community has contributed code, documentation, architectural review and other support. These include representatives from Rackspace, HP, RedHat, Nebula and more. All members below have signed the OpenStack CLA prior to writing any Barbican code.
- Jarret Raim is the proposed technical lead. Jarret is the Cloud Security Product Manager at Rackspace and is in charge of the Barbican effort. Jarret did security research as part of his undergraduate and graduate work. Since graduating, Jarret has worked as a developer at Southwest Research Institute and a security consultant at Denim Group before moving to Rackspace.
- John Wood is a developer on the Barbican project. John is a senior developer at Rackspace. John has worked on enterprise systems at Southwest Research Institute, 360Commerce (now Oracle Retail) and Nationwide. Prior to that he developed firmware for telecommunications and signal processing applications.
- Douglas Mendizabal is a developer on the Barbican project. Doug joined Rackspace earlier this year, where he contributed to Project Meniscus before joining the Barbican team. Prior to joining Rackspace, Doug was a secure software development consultant at Denim Group where he helped development of web apps, mobile apps, and web services in various different languages.
- Paul Kehrer is our crypto expert on the Barbican project. He has experience running a public certificate authority as well as doing significant open source work in cryptography by writing and maintaining r509, a ruby library for managing a certificate infrastructure and cryptography, a modern python crypto library.
- John Vrbanac is our test lead on the Barbican effort. John's background is primarily in enterprise software development. Before joining Rackspace and the Barbican effort, John was a lead developer for Pearson on their flagship online testing platform. Recently, he has been contributing to the open-source world through the writing and maintaining of Specter, a code-centric Python BDD framework, as well as contributing to projects such as: Pynsive, DefinitelyTyped, and the Ubuntu API website.
- Chad Lung is a developer on the Barbican project. Chad previously worked on Project Meniscus (a logging service) and Atom Hopper. Chad joined Rackspace in 2011. Previously he worked for Pearson.
- Steven Gonzalez is a developer on the Barbican project. Steven previously worked on Project Meniscus (a logging service) and joined Rackspace in 2013. Previously he worked at UTSA.
Barbican is currently on StackForge using Gerrit and Jenkins to run the unit test suite and flake8. An integration and testing environment are set up on Rackspace public cloud. In addition to the Cloud environments, Barbican has two staging environments with physical servers and HSMs for testing integration and replication use cases.
Tasks for Incubation (Barbican was incubated on March 10, 2014)
The following are tasks for Barbican that have been brought up as part of the incubation process as well as some changes that we felt were in the spirit of incubation.
- [Review] Move to global requirements
- [Review] Move Barbican to pbr
- [Review] Use oslo.messaging instead of celery
- [Review] Set up a basic devstack-gate job (https://review.openstack.org/#/c/57098/)
- [Review] Move to supporting testr