Jump to: navigation, search

Difference between revisions of "Barbican/Incubation"

(Added team)
(Icehouse)
 
(38 intermediate revisions by 7 users not shown)
Line 9: Line 9:
  
 
== Mission Statement ==  
 
== Mission Statement ==  
To produce and OpenStack key management API that simplifies the creation, management and use of keying material for encryption purposes. We plan to achieve this be 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.
+
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 ==
 
== Detailed Description ==
Line 21: Line 21:
 
* 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.
 
* 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.
 
* 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).
 
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).
 +
 +
== Scope ==
 +
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. 
 +
 +
=== Deliverables ===
 +
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
  
 
== Roadmap ==
 
== Roadmap ==
Barbican has been participating in the OpenStack release toolchain for the Havanna cycle. Our blueprints and milestones can be seen [https://launchpad.net/barbican Launchpad]. As a result, we have completed our MVP set of functionality which is detailed below along with our future plans.  
+
Barbican has been participating in the OpenStack release toolchain for the Havana cycle. Our blueprints and milestones can be seen in [https://launchpad.net/barbican 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
  
 
=== Havana (1.0) ===
 
=== 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 ===
 
=== Icehouse ===
*
+
* Support for [https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes transparent encryption for Cinder volumes]
*
+
* KIMP backend support (based on a third-party library contribution)
*
+
* KDS service for [https://wiki.openstack.org/wiki/MessageSecurity message signing]
 +
* Support for provisioning SSL/TLS certificates from public CAs (plugin based, Symantec CAs first)
 +
* Support API for [https://fedorahosted.org/certmonger/ certmonger] tool
 +
* [https://wiki.openstack.org/wiki/Barbican/Blueprints/dogtag-plugin Backend support for Dogtag (based on third party contributions)]
 +
* Support for [https://wiki.openstack.org/wiki/Swift/server-side-enc object encryption in swift] (third party contributions)
  
 
=== Future ===
 
=== Future ===
*
+
* [https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates 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 ==
 
== Project Resources ==
Line 50: Line 78:
  
 
== Team ==
 
== Team ==
* [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 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.
+
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.
* [https://github.com/jfwood John Wood] is a developer on the Barbican project.
+
 
* [https://github.com/dmend Douglas Mendizabal] is a developer on the Barbican project.
+
* [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/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/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.  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.
 +
* [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 cryptography by writing and maintaining [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/jmvrbanac 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 [https://github.com/jmvrbanac/specter Specter], a code-centric Python BDD framework, as well as contributing to projects such as: [https://github.com/zinic/pynsive Pynsive], [https://github.com/borisyankov/DefinitelyTyped DefinitelyTyped], and the [http://developer.ubuntu.com/api/qml/sdk-1.0/ Ubuntu API website].
 +
* [https://github.com/chadlung Chad Lung] is a developer on the Barbican project. Chad previously worked on [https://github.com/ProjectMeniscus/meniscus Project Meniscus] (a logging service) and [http://atomhopper.org/ Atom Hopper]. Chad joined Rackspace in 2011. Previously he worked for Pearson.
 +
* [https://github.com/stevendgonzales Steven Gonzalez] is a developer on the Barbican project. Steven previously worked on [https://github.com/ProjectMeniscus/meniscus Project Meniscus] (a logging service) and joined Rackspace in 2013. Previously he worked at UTSA.
 +
 
 +
== 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.
 +
 
 +
== 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.
 +
 
 +
===  Barbican ===
 +
# [[https://review.openstack.org/#/c/64468/ Review]] Move to global requirements
 +
# [[https://review.openstack.org/#/c/60551/ Review]] Move Barbican to pbr
 +
# [[https://review.openstack.org/#/c/60427/ Review]] Use oslo.messaging instead of celery
 +
# [[https://review.openstack.org/#/c/74530 Review]] Set up a basic devstack-gate job (https://review.openstack.org/#/c/57098/)
 +
# [[https://review.openstack.org/#/c/69512/ Review]] Move to supporting testr
 +
 
 +
=== python-barbicanclient ===
 +
# [[https://review.openstack.org/#/c/64573/ Review]] Rename command line client to barbican to be more in line with rest of openstack
 +
# [[https://review.openstack.org/#/c/64851/ Review]] Migrate python-barbicanclient to pbr
 +
# [[https://github.com/stackforge/python-barbicanclient GitHub] / [https://review.openstack.org/#/q/status:merged+project:stackforge/python-barbicanclient,n,z Gerrit] / [https://review.openstack.org/#/c/60101 Review]] Move python-barbicanclient repository to stackforge

Latest revision as of 19:45, 2 April 2014

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

Scope

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.

Deliverables

The Barbican project will produce two deliverables:

  1. barbican - Python ReST API for performing key management
  2. python-barbicanclient - A python library providing access to features of the Barbican API

Roadmap

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

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

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

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.

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.

Barbican

  1. [Review] Move to global requirements
  2. [Review] Move Barbican to pbr
  3. [Review] Use oslo.messaging instead of celery
  4. [Review] Set up a basic devstack-gate job (https://review.openstack.org/#/c/57098/)
  5. [Review] Move to supporting testr

python-barbicanclient

  1. [Review] Rename command line client to barbican to be more in line with rest of openstack
  2. [Review] Migrate python-barbicanclient to pbr
  3. [GitHub / Gerrit / Review] Move python-barbicanclient repository to stackforge