Jump to: navigation, search

Difference between revisions of "Barbican/Incubation"

m (Mission Statement)
m (Team: Added more information for John Wood.)
Line 66: Line 66:
  
 
* [https://github.com/jarretraim 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.
 
* [https://github.com/jarretraim 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.
* [https://github.com/jfwood John Wood] is a developer on the Barbican project.
+
* [https://github.com/jfwood 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.
 
* [https://github.com/dmend Douglas Mendizabal] is a developer on the Barbican project.
 
* [https://github.com/dmend Douglas Mendizabal] is a developer on the Barbican project.
 
* [https://github.com/reaperhulk 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 the cryptography by writing and maintaing [https://github.com/r509/r509 r509], a ruby library for managing a certificate infrastructure and [https://github.com/pyca/cryptography cryptography], a modern python crypto library.
 
* [https://github.com/reaperhulk 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 the cryptography by writing and maintaing [https://github.com/r509/r509 r509], a ruby library for managing a certificate infrastructure and [https://github.com/pyca/cryptography cryptography], a modern python crypto library.

Revision as of 17:56, 25 November 2013

Project Codename

Barbican

Trademarks

There are no other parts of the Barbican project that will be part of OpenStack.

Summary

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.

Mission Statement

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.

Detailed Description

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).

Roadmap

Barbican has been participating in the OpenStack release toolchain for the Havanna 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.

Havana (1.0)

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)

Icehouse

  • Boot verification support (use for transparent disk encryption)
  • 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)

Future

  • 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

Project Resources

Team

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.
  • 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 the cryptography by writing and maintaing r509, a ruby library for managing a certificate infrastructure and cryptography, a modern python crypto library.

Infrastructure Requirements

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.