Jump to: navigation, search

Difference between revisions of "Marshal"

(Boot VM and setup Marshal)
(Key provisioning in Barbican)
Line 14: Line 14:
  
 
=== Key provisioning in Barbican ===
 
=== Key provisioning in Barbican ===
 +
 +
Key provisioning will be done by the user by log-in in to the Horizon dashboard and create secret. User may choose to come with his own key or he/she can order one from Barbican. Once the key is created he should define certain policy on that secret to avoid illegal access.
 +
 
[[File:KeyProvisioningInBarbican.jpg]]
 
[[File:KeyProvisioningInBarbican.jpg]]
  

Revision as of 22:22, 18 August 2015

Introduction

Over the period of last 5 years OpenStack community has provided support for core cloud (e. g. Nova, Glance, Cinder, Neutron, Keystone, Barbican etc …) services which are mandatory for any infrastructure cloud. It has also provided supporting services (Heat, Horizon, Ceilometer, Monasca), which helps cloud providers and consumers to interact and manage cloud resources. Volume encryption is one of the areas, which still needs more attentions, as the current model has some gaps. Project Marshal is new initiative in community, which support and streamline volume encryption use cases and provide data security a rest.

What is Marshal?

OpenStack Barbican has gone through long ways from key storage to key manager. We have implemented many cool features in it and some are in pipeline, but still it is not well integrated to support volume encryption use cases, which is one of the basic needs. In the current flow of volume encryption, user chooses to create an encrypted volume using cinder API, an encryption key will be created in Barbican. Key reference will be stored in Cinder with disk metadata. Key will be retrieved by Nova from the Barbican and provided to dm-crypt while attaching the disk to VM, all I/O to the disk will be encrypted.

There are some gaps in the current flow, e.g. it is not very transparent to the end users, only one key can be used at a time and there is no way users can change the encryption keys. This flow is also very tightly integrated with OpenStack components but there are cases where users want to use their existing KMS. The current volume encryption implementation focus mostly on Linux based VM but not support for Windows VM. On-premise KMS integration is another use case, which is not, yet solves.

Marshal is a new service (or tool) in community to fill the above-mentioned gaps; it solves the volume encryption problem with different approach. Marshal is an agent service running inside virtual machines, which will be responsible for securely fetching encryption key from KMS (Barbican). This agent will be interfacing with disk encryption subsystem of underlying operating system to encrypt/decrypt the disk I/O.

In case of Linux based virtual machines this agent will be interfacing with dm-crypt and for Microsoft it will be interfacing with Bit-locker. The agent provides abstraction service and can be integrated with other encryption subsystem if needed. This agent reads key from KMS and create a temp file volatile memory, it forgets the key immediately after providing to disk encryption subsystem.

Activity Diagrams

Key provisioning in Barbican

Key provisioning will be done by the user by log-in in to the Horizon dashboard and create secret. User may choose to come with his own key or he/she can order one from Barbican. Once the key is created he should define certain policy on that secret to avoid illegal access.

KeyProvisioningInBarbican.jpg

Volume Creation (Plain)

CreateCinderDisk.jpg

Boot VM and setup Marshal

SetDiskForEncryption.jpg

Benefits

Current OpenStack volume encryption is very static in nature, only one key can be used and it won't be changed. Marshal agent can able to change the encryption keys and re-key the data. Marshal agent will provide ability to choose the keys from KMS system to be used for disk encryption. OpenStack volume encryption flow is very rigidly defined, where Cinder creates key in KMS and Nova provide that key to the VM encryption subsystem. This process is mostly abstracted from users. This agent will help older OpenStack deployment to integrate with Barbican (or any KMS) system to consume keys and use them for the disk encryption. This agent provides abstraction and can be integrate with customer's on-prem KMS systems. It can also be integrated with HSM devises directly using Castellan, KMIP or PKCS11 interface. Marshal agent will provide more flexibility to the end users by providing fine-grained control. Marshal will allow features like full disk encryption, root disk encrypt and different partitions of the disk, which is not covered in current flow.

Roadmap

1. Entire disk encryption with one key stored in KMS. 1. dm-crypt 2. bitlocker 2. Fine grained (root disk, individual partition) encryption support with one key. 3. Multi key encryption support and rekey data in volume. 4. Ability to fetch keys from on-prem KMS. 5. LBaaS certificate monitoring 6. Provisioning certificate from CA and installation.

Challenges and Workarounds

Following are the challenges we are seeing in this approach 1. Agent authentication to Barbican (or any KMS). 1. Use of certificate based auth from Keystone, which is on the way for Liberty. Agent will be assigned a certificate in this mode. 2. Use of trust (Keystone concept) to authenticate, trust will be provided to agent. 3. Use per secret policy, which is in Barbican roadmap. 4. Per secret license/grant ticket to access the secret. 2. Security of keys in transit 1. Agent will be talking to Barbican on secured and trusted network over SSL. 2. Transport keys can be used to securely fetch key from KMS. Specially when collecting keys from on-prem KMS. 3. How to inject agent in the VM 1. Create image (Linux/Win) with the Marshal agent. 2. Provide deb/zip package

Next Steps

TDB