Difference between revisions of "Marshal"

Revision as of 20:55, 14 October 2015

Introduction

Over the last 5 years, the OpenStack community has provided support for core cloud services such as Nova, Glance, Cinder, Neutron, Keystone, and Barbican. These core services provide the fundamental features for most OpenStack deployments. The community has also also done a great job, providing support services such as Heat, Horizon, Ceilometer, and Monasca, which helps cloud providers and consumers to interact with and manage cloud resources. One area which has not received as much attention is the area of volume encryption. The import of data security is evident now more than ever. With scrutiny of OpenStack’s current volume encryption offering, it has become apparent that large gaps exist and this is an area deserving of more attention. Project Marshal is a new initiative in the community aimed at addressing those gaps, and improving overall data security within the OpenStack platform.

Recent Evolution Of OpenStack Volume Encryption

Recently, OpenStack Barbican has evolved from a key storage facility to more of a key management facility. It has received many useful features and some are still in the pipeline, but it is still not used in handling many of the desired volume encryption use cases. In the current flow of volume encryption, when a user chooses to create an encrypted volume using the Cinder API, an associated encryption key will be created in Barbican. A key reference is stored in Cinder along with the disk metadata. The key is later retrieved by Nova from Barbican and provided to the disk encryption subsystem (eg, dm-crypt) while attaching the disk to VM, causing all subsequent I/O to the disk to be encrypted. There are some gaps in the current flow. E.g., it is not very transparent to end users; only one key can be used at a time and there is no way users can change the encryption key. This flow is very tightly integrated with OpenStack components. This is good for users of those OpenStack components, but there are cases where, e.g., users want to use a non-OpenStack KMS. As well, the current volume encryption implementation focus mostly on Linux based VMs with little support for Windows VMs. On-premise KMS (vs cloud-based KMS) is another use case which is not covered in the current flow.

What is Marshal?

Marshal is a new service/tool in the OpenStack community aimed at filling the above-mentioned gaps; it approaches volume encryption in a new way. Marshal is an agent service running inside guest virtual machines (VMs), which will be responsible for securely fetching encryption keys from the KMS (e.g., Barbican). This agent will interface with the disk encryption subsystem of underlying operating system to encrypt/decrypt the disk I/O. In the case of Linux VMs, this agent will be interfacing with dm-crypt and for Microsoft VMs, it will be interfacing with Bit-locker. The Marshal agent provides an abstraction service and can be integrated with other encryption subsystem if needed. The agent will read keys from the KMS – storing them only in temporary/volatile storage – then forgets the keys immediately after providing them as needed to the disk encryption subsystem. The foreseen benefits of this approach are outlined below under the “Benefits” section.

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.

Disk creation in Cinder

Disk/Volume are managed in Cinder and user will interface with Cinder through Horizon to provision virtual disks. In the flow given below, we are creating a plain disk which means encryption key will not be created in the Barbican. I an alternative flow user will opt to create encrypted disk and key will automatically created in the Barbican.

Boot VM and setup Marshal

User would choose to boot a new VM from an image which is build with Marshal agent, alternatively user can use an exiting VM. User will provide key information stored in Barbican to be used by Marshal agent, there are multiple way to provide keys to the new VM as below

1. In very basic user will provide the key id using Cloud-Config Scripting. Key id will be stored in certain location of the new VM to be consumed by Marshal agent.
2. User will generate key access ticket (KAT) for particular keys and provide the KAT to the VM using Customization Script Source. This KAT will be stored in VM temporary directory for consumed by Marshal. This approach need some enhancement in Barbican.
3. User will use a encrypted volume which he/she has created before and volume meta-data will provide the key id. Marshal will pick the key info from volume meta-data while configuration.

User will use command provided by Marshal agent to configure disk encryption. User will get ability to encrypt

1. Fine grained (root disk, individual partition) encryption support with one key.
2. Multi key encryption support and rekey data in volume.

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.

   * dm-crypt
   * bitlocker

1. Fine grained (root disk, individual partition) encryption support with one key.
2. Multi key encryption support and rekey data in volume.
3. Ability to fetch keys from on-prem KMS.
4. Key interface for containers.
5. LBaaS certificate monitoring
6. Provisioning certificate from CA and installation.
7. Containers Integration.
8. Encryption agent for IoT device.

Challenges and Workarounds

Following are the challenges we are seeing in this approach along with possible workaround

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 Key Access Ticket (KAT) to access the secret.

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.

How to inject agent in the VM

1. Use of generic image (Linux/Win) with the Marshal agent.
2. Use of deb/zip package

Next Steps

<TDB>