Difference between revisions of "Trove/TroveSSL"

Revision as of 13:27, 28 August 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 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 portion of the signing certificate if one was used (or .truststore for cassandra, etc.).

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 Generation

There will need to be an implementable driver for SSL key generation and signing. Obviously there will be a desire to implement a Barbican driver once that project supports 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

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.