Jump to: navigation, search

Difference between revisions of "Trove/TroveSSL"

(Created page with "== Description == Most datastores have support for SSL connections from clients. We should use that. Deployers should have an option of enabling SSL by default during instan...")
 
 
Line 78: Line 78:
 
* enable_ssl(ssl_payload))
 
* enable_ssl(ssl_payload))
 
"ssl_payload" => { "public_key": "...", "private_key": "...", "ca_cert": "..." }
 
"ssl_payload" => { "public_key": "...", "private_key": "...", "ca_cert": "..." }
−
Where public_key is either the SSL public key for a datastore if required (None if not), private_key is the SSL private key
+
 
−
for a datastore if required (or cert file for mongo, .keystore for cassandra, etc.), and ca_cert is the public key
+
Where public_key, private_key, and ca_cert contain the information needed for the guest agent SSL handler to successfully
−
portion of the signing certificate if one was used (or .truststore for cassandra, etc.).
+
configure an instance for SSL. The raw values of public_key, private_key, and ca_cert are dependent upon the driver. For example,
 +
private_key could be an HREF to a file, the full body of a private key (or cert file for mongo, .keystore for cassandra, etc.), or nothing at all.
  
 
This API call should perform all logic needed to setup SSL except the restart that is required for several datastores.
 
This API call should perform all logic needed to setup SSL except the restart that is required for several datastores.
Line 92: Line 93:
 
=== SSL Drivers ===
 
=== SSL Drivers ===
  
−
==== Key Generation ====
+
==== Key Provider ====
  
−
There will need to be an implementable driver for SSL key generation and signing.
+
There will need to be an implementable driver interface for an SSL key provider. The provider
−
Obviously there will be a desire to implement a Barbican driver once that project supports
+
will be paired with an installer and will produce the appropriate ssl_payload.
−
managing CA certs and SSL key generation. In the meantime we should also be able to
 
−
implement drivers which manage keys and key generation for each datastore in other ways.
 
−
Keygen drivers should create an appropriate SSL payload.
 
  
 
==== Key Installers ====
 
==== Key Installers ====
Line 105: Line 103:
 
payload (either from the prepare call or the enable_ssl call) which performs the setup and configuration
 
payload (either from the prepare call or the enable_ssl call) which performs the setup and configuration
 
changes required for SSL to be enabled.
 
changes required for SSL to be enabled.
 +
 +
== Example Implementations ==
 +
 +
=== No Op ===
 +
 +
ssl_payload => {"public_key": None, "private_key": None, "ca_cert": None}
 +
guest behaviour => Do nothing.
 +
 +
=== HREF/Swift ===
 +
 +
ssl_payload => {"public_key": "https://...", "private_key": "https://...", "ca_cert": "https://..."}
 +
guest behaviour => Download files using the given href's and setup ssl.
 +
 +
=== Keys ===
 +
 +
ssl_payload => {"public_key": "BEGIN RSA...", "private_key": "...", "ca_cert": "..."}
 +
guest behaviour => Use the keys given in the payload and setup ssl.

Latest revision as of 22:55, 9 September 2014

Description

Most datastores have support for SSL connections from clients. We should use that.

Deployers should have an option of enabling SSL by default during instance creation or, also optionally, enabling SSL on existing instances.

Justification/Benefits

  • Trove users should have a way to protect their data while it is in flight.
  • No, seriously. Who pipes unencrypted data over the *internet*?

Use Case Requirements

MySQL

MySQL SSL setup requires four things be placed on the guest.

  • Public/Private keypair to use for SSL that have been signed by a CA pair.
  • The CA cert that corresponds to the key used to sign the SSL pair.
  • A configuration file containing the flags which direct MySQL to use the three keys above.

See http://dev.mysql.com/doc/refman/5.0/en/ssl-connections.html for more details.

PostgreSQL

PostgreSQL SSL setup is similar to the MySQL setup. See http://www.postgresql.org/docs/9.1/static/ssl-tcp.html for more details.

MongoDB

MongoDB SSL setup requires three things be placed on the guest.

  • SSL cert file containing public and private keys.
  • The CA cert that corresponds to the key used to sing the SSL pair.
  • A configuration file containing the flags which direct MongoDB to use the keys above.

See http://docs.mongodb.org/manual/tutorial/configure-ssl/ for more details.

Cassandra

Cassandra requires all nodes in a cluster to contain the keys for all other nodes in a cluster. The process, however, appears very similar to the above. It requires that the keys be placed on the guest and an appropriate configuration value be set. Comments requested from Cassandra deployers.

See http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/secureSslEncryptionTOC.html for more details.

Impacts

Configuration

  • SSL driver option per datastore in task manager configuration.
  • Option for SSL on create per datastore in task manager configuration.

Database

  • No change.

Public API

  • Management API call to enable SSL on existing instances.

CLI interface

  • trove mgmt-ssl-enable <instance>
  • trove mgmt-ssl-show <instance>

REST Part

  • POST /mgmt/instances/<instance>/ssl => Run SSL setup for a guest. No POST body required.
  • GET /mgmt/instances/<instance>/ssl => Check if SSL is setup for a guest. Body: { "ssl": { "enabled": true } }

Internal API

  • Adds an optional "ssl" argument to the prepare call containing necessary payloads.

RPC API description

Existing instances can be configured for SSL through an API call:

  • enable_ssl(ssl_payload))

"ssl_payload" => { "public_key": "...", "private_key": "...", "ca_cert": "..." }

Where public_key, private_key, and ca_cert contain the information needed for the guest agent SSL handler to successfully configure an instance for SSL. The raw values of public_key, private_key, and ca_cert are dependent upon the driver. For example, private_key could be an HREF to a file, the full body of a private key (or cert file for mongo, .keystore for cassandra, etc.), or nothing at all.

This API call should perform all logic needed to setup SSL except the restart that is required for several datastores. Instead, something like a "RESTART_REQUIRED_SSL" status should be set on the instance.

Guest Agent

  • Agent needs to handle SSL payloads appropriately depending on the SSL driver used.
  • Agent must generate/modify the appropriate configuration files to enable SSL.

SSL Drivers

Key Provider

There will need to be an implementable driver interface for an SSL key provider. The provider will be paired with an installer and will produce the appropriate ssl_payload.

Key Installers

Each datastore guest agent that supports SSL should have a code path which consumes an SSL payload (either from the prepare call or the enable_ssl call) which performs the setup and configuration changes required for SSL to be enabled.

Example Implementations

No Op

ssl_payload => {"public_key": None, "private_key": None, "ca_cert": None} guest behaviour => Do nothing.

HREF/Swift

ssl_payload => {"public_key": "https://...", "private_key": "https://...", "ca_cert": "https://..."} guest behaviour => Download files using the given href's and setup ssl.

Keys

ssl_payload => {"public_key": "BEGIN RSA...", "private_key": "...", "ca_cert": "..."} guest behaviour => Use the keys given in the payload and setup ssl.

Retrieved from "https://wiki.openstack.org/w/index.php?title=Trove/TroveSSL&oldid=62331"