Difference between revisions of "Trove/Barbican-integration"
(Created page with "= Barbican integration = == Barbican description == Barbican is a tenant aware key and secrets management service for cloud applications, including symmetric and asymmetric k...") |
(→Justification) |
||
(14 intermediate revisions by the same user not shown) | |||
Line 19: | Line 19: | ||
Barbican designed to provide Secret delivery and storage. By the default, Barbican provides AES order with key length 256 bit and CBC mode. | Barbican designed to provide Secret delivery and storage. By the default, Barbican provides AES order with key length 256 bit and CBC mode. | ||
+ | |||
+ | Note: Barbican integration was [https://blueprints.launchpad.net/cinder/+spec/encryption-with-barbican proposed] for Cinder. | ||
=== Benefits === | === Benefits === | ||
+ | Since we have security issue with passwords/keys in conf file we need to provide and ability to use another implementations that are not the part of Trove official distro. That would take off all concerns in front of OSSG. Provided interface takes off all responsibility against use of passwords/key in conf files by allowing to delegate key management to 3d party tools through side implementation of BaseSecurityWorkflow that's not the part of official distro, and existing configuration are might be marked as "for developing/testing only". | ||
+ | Advantages. | ||
* Trove would no longer need to store backup encyption password in plain text guest configuration file (which seems to be a security issue). Same takes place for replication user password. | * Trove would no longer need to store backup encyption password in plain text guest configuration file (which seems to be a security issue). Same takes place for replication user password. | ||
− | * Advanced OpenStack integration. | + | * Advanced OpenStack integration. |
== Impacts == | == Impacts == | ||
− | + | === Reengeneering === | |
Existing code will be refactored to extract Security workflow into it's own package: | Existing code will be refactored to extract Security workflow into it's own package: | ||
* '' trove/security '' | * '' trove/security '' | ||
Line 35: | Line 39: | ||
import abc | import abc | ||
import six | import six | ||
− | |||
@six.add_metaclass(abc.ABCMeta) | @six.add_metaclass(abc.ABCMeta) | ||
class BaseSecurityWorkflow(object): | class BaseSecurityWorkflow(object): | ||
− | |||
@abc.abstractmethod | @abc.abstractmethod | ||
− | def | + | def _get_or_create_key(self, |
− | + | name=None, | |
− | + | alg="AES", | |
− | + | bit_length=256, | |
− | + | mode="cbc", | |
− | + | payload_content_type= | |
− | + | "application/octet-stream"): | |
− | + | """Creates a key by given parameters.""" | |
− | |||
− | |||
− | |||
@abc.abstractmethod | @abc.abstractmethod | ||
def get_backup_encyption_key(self): | def get_backup_encyption_key(self): | ||
− | + | """Implements backup encryption password delivery.""" | |
− | |||
@abc.abstractmethod | @abc.abstractmethod | ||
def get_replication_user_key(self): | def get_replication_user_key(self): | ||
− | + | """Implements replication user key delivery.""" | |
+ | |||
+ | Two implementation of BaseSecurityWorkflow class would be added: | ||
+ | * Proprietary (what actually we have now: passwords are retrieved from configuration file, same for each new guest deployment) | ||
+ | * Barbican-based implementation (AES key delivery). | ||
+ | |||
+ | ==== Barbican key delivery workflow ==== | ||
+ | For delivering a key barbican requieres the name for it. To satisfy this requirement as the name of the Key(in terms of Barbican - Order) | ||
+ | can be used ''backup ID'' and ''backup Name''. | ||
+ | |||
+ | === Configurations === | ||
+ | New options would be proposed: | ||
+ | |||
+ | * Name: ''barbican_url'' | ||
+ | ** Type: String | ||
+ | ** Upkeep: barbican endpoint url | ||
+ | ** Value: | ||
+ | *** default: localhost:9311 | ||
+ | |||
+ | * Name: ''remote_barbican_client'' | ||
+ | ** Type: String | ||
+ | ** Upkeep: barbican client class implementation | ||
+ | ** Value: | ||
+ | *** Default: trove.common.remote.barbican_client | ||
+ | |||
+ | * Name: ''security_strategy'' | ||
+ | ** Type: String | ||
+ | ** Upkeep: implementation classpath | ||
+ | ** Value: | ||
+ | *** default: ''trove.security.proprietary.SecurityWorkflow'' | ||
+ | *** possible values: ''trove.security.barbican.SecurityWorkflow'' | ||
+ | |||
+ | === Database === | ||
+ | No changes | ||
+ | |||
+ | === Public API === | ||
+ | No changes | ||
+ | |||
+ | === Internal API === | ||
+ | No changes |
Latest revision as of 21:16, 15 August 2014
Contents
Barbican integration
Barbican description
Barbican is a tenant aware key and secrets management service for cloud applications, including symmetric and asymmetric keys, raw secrets and support for public and private SSL certificates. See Barbican at Launchpad.
Description
Trove uses encryption/decryption for backups (if encryption enabled). For this workflow Trove uses:
- Algorithm: AES
- Mode: cbc
- Key lenght: 256
- Payload content type: application/octet-stream
For performing encyption/decryption Trove uses:
- openssl util
Justification/Benefits
Justification
Barbican designed to provide Secret delivery and storage. By the default, Barbican provides AES order with key length 256 bit and CBC mode.
Note: Barbican integration was proposed for Cinder.
Benefits
Since we have security issue with passwords/keys in conf file we need to provide and ability to use another implementations that are not the part of Trove official distro. That would take off all concerns in front of OSSG. Provided interface takes off all responsibility against use of passwords/key in conf files by allowing to delegate key management to 3d party tools through side implementation of BaseSecurityWorkflow that's not the part of official distro, and existing configuration are might be marked as "for developing/testing only".
Advantages.
- Trove would no longer need to store backup encyption password in plain text guest configuration file (which seems to be a security issue). Same takes place for replication user password.
- Advanced OpenStack integration.
Impacts
Reengeneering
Existing code will be refactored to extract Security workflow into it's own package:
- trove/security
Abstract layer for Security workflow will be proposed:
- BaseSecurityWorkflow
- Implementation
import abc import six @six.add_metaclass(abc.ABCMeta) class BaseSecurityWorkflow(object): @abc.abstractmethod def _get_or_create_key(self, name=None, alg="AES", bit_length=256, mode="cbc", payload_content_type= "application/octet-stream"): """Creates a key by given parameters.""" @abc.abstractmethod def get_backup_encyption_key(self): """Implements backup encryption password delivery.""" @abc.abstractmethod def get_replication_user_key(self): """Implements replication user key delivery."""
Two implementation of BaseSecurityWorkflow class would be added:
- Proprietary (what actually we have now: passwords are retrieved from configuration file, same for each new guest deployment)
- Barbican-based implementation (AES key delivery).
Barbican key delivery workflow
For delivering a key barbican requieres the name for it. To satisfy this requirement as the name of the Key(in terms of Barbican - Order) can be used backup ID and backup Name.
Configurations
New options would be proposed:
- Name: barbican_url
- Type: String
- Upkeep: barbican endpoint url
- Value:
- default: localhost:9311
- Name: remote_barbican_client
- Type: String
- Upkeep: barbican client class implementation
- Value:
- Default: trove.common.remote.barbican_client
- Name: security_strategy
- Type: String
- Upkeep: implementation classpath
- Value:
- default: trove.security.proprietary.SecurityWorkflow
- possible values: trove.security.barbican.SecurityWorkflow
Database
No changes
Public API
No changes
Internal API
No changes