From 3c5392e75dfd6790762f5d212aeb1e7c877cbd1f Mon Sep 17 00:00:00 2001 From: Chandan kumar Date: Fri, 22 Nov 2013 18:29:25 +0530 Subject: [PATCH] Fixes typo in key management Change-Id: I465af5b13ce9d1dacb8a25da0e04b0d500545c51 Closes-Bug: #1253844 --- doc/security-guide/ch048_key-management.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/security-guide/ch048_key-management.xml b/doc/security-guide/ch048_key-management.xml index 35e356c814..26657c981c 100644 --- a/doc/security-guide/ch048_key-management.xml +++ b/doc/security-guide/ch048_key-management.xml @@ -1,7 +1,7 @@ Key Management - To address the often mentioned concern of tenant data privacy and limiting cloud provider liability, there is greater interest within the OpenStack community to make data encryption more ubiquitous. It is relatively easy for an end-user to encrypt their data prior to saving it to the cloud, and a this is a viable path for tenant objects such as media files, database archives among others. However, when client side encryption is used for virtual machine images, block storage etc, client intervention is necessary in the form of presenting keys to unlock the data for further use. To seamlessly secure the data and yet have it accessible without burdening the client with having to manage their keys and interactively provide them calls for a key management service within OpenStack. Providing encryption and key management services as part of OpenStack eases data-at-rest security adoption, addresses customer concerns about the privacy and misuse of their data with the added advantage of limiting cloud provider liability. Provider liability is of concern in multi-tenant public clouds with respect to handing over tenant data during a misuse investigation. + To address the often mentioned concern of tenant data privacy and limiting cloud provider liability, there is greater interest within the OpenStack community to make data encryption more ubiquitous. It is relatively easy for an end-user to encrypt their data prior to saving it to the cloud, and this is a viable path for tenant objects such as media files, database archives among others. However, when client side encryption is used for virtual machine images, block storage etc, client intervention is necessary in the form of presenting keys to unlock the data for further use. To seamlessly secure the data and yet have it accessible without burdening the client with having to manage their keys and interactively provide them calls for a key management service within OpenStack. Providing encryption and key management services as part of OpenStack eases data-at-rest security adoption, addresses customer concerns about the privacy and misuse of their data with the added advantage of limiting cloud provider liability. Provider liability is of concern in multi-tenant public clouds with respect to handing over tenant data during a misuse investigation. A key management service is in the early stages of being developed and has a way to go before becoming an official component of OpenStack. Refer to https://github.com/cloudkeep/barbican/wiki/_pages for details. It shall support the creation of keys, and their secure saving (with a service master-key). Some of the design questions still being debated are how much of the Key Management Interchange Protocol (KMIP) to support, key formats, and certificate management.  The key manager will be pluggable to facilitate deployments that need a third-party Hardware Security Module (HSM). OpenStack Block Storage, Cinder, is the first service looking to integrate with the key manager to provide volume encryption.