From 5a89a60c09915088e5f1817a4185c6e940383f00 Mon Sep 17 00:00:00 2001 From: Adam Harwell Date: Thu, 23 Oct 2014 19:07:09 -0500 Subject: [PATCH] TLS Data Security Overview Here we define the overall strategy for dealing with secure TLS data in Octavia. There are several areas that need attention, and they are detailed in this spec. Barbican will be our default secure storage and certificate signing service, but the interfaces should remain generic. Sequence diagrams now included. Change-Id: Icbbea8e37af0ce13fd959543403f2b01b8c7d17b Implements: blueprint tls-data-security --- specs/version0.5/tls-data-security-1.diag | 16 +++ specs/version0.5/tls-data-security-2.diag | 29 ++++ specs/version0.5/tls-data-security.rst | 164 ++++++++++++++++++++++ 3 files changed, 209 insertions(+) create mode 100644 specs/version0.5/tls-data-security-1.diag create mode 100644 specs/version0.5/tls-data-security-2.diag create mode 100644 specs/version0.5/tls-data-security.rst diff --git a/specs/version0.5/tls-data-security-1.diag b/specs/version0.5/tls-data-security-1.diag new file mode 100644 index 0000000000..6af9c12cc2 --- /dev/null +++ b/specs/version0.5/tls-data-security-1.diag @@ -0,0 +1,16 @@ +seqdiag { + span_height = 10; + === If Certificate is pre-stored in Barbican === + User => Octavia [label="Create LB with TLS (passing tls_certificate_id)", note="HTTPS", return="202/400/401"] { + Octavia => Barbican [label="Fetch Certificate Container", note="HTTPS", return="Certificate Data"]; + } + === If Certificate is passed directly to Octavia === + User => Octavia [label="Create LB with TLS (passing tls_certificate, tls_private_key, etc)", note="HTTPS", return=" +202/400/401"] { + Octavia => Barbican [label="Store Secrets / Certificate Container", note="HTTPS", return="tls_certificate_id"]; + } + Octavia -> Octavia [label="Store tls_certificate_id"]; + === After certificate handling, in both cases === + Octavia -> Octavia [label="Fetch Amphora from Spare Pool"]; + Octavia => "Amphora API" [label="Configure Amphora", note="HTTPS", return="Update LB Status"]; +} diff --git a/specs/version0.5/tls-data-security-2.diag b/specs/version0.5/tls-data-security-2.diag new file mode 100644 index 0000000000..b98381b4c5 --- /dev/null +++ b/specs/version0.5/tls-data-security-2.diag @@ -0,0 +1,29 @@ +seqdiag { + span_height = 10; + activation = none; + === In Octavia === + Barbican; + Octavia => Nova [label="Create new Amphora", note="include Octavia Controller certificate and IP as Metadata"]; + loop { + Octavia => Nova [label="Poll for ACTIVE Amphora", return="Amphora Management IP"]; + } + Octavia -> Octavia [label="Store Amphora IP"]; + === Meanwhile, in the Amphora === + Amphora -> Amphora [label="Generate private key and CSR"]; + Amphora => Octavia [label="Request Certificate Signing", return = "Signed Certificate"] { + Octavia -> Octavia [label="Verify Amphora by source IP"]; + Octavia => Barbican [label="Process CSR using private CA", return="Signed Certificate"]; + } + Amphora -> Amphora [label="Start Services (API, Heartbeat)"]; + "Amphora Heartbeat" -> Octavia [label="Announce", note="UDP? HTTPS?"] { + Octavia -> Octavia [label="Verify Amphora by source IP (UDP) or certificate (HTTPS)"]; + === If Verification fails === + Octavia -> Octavia [label="Log and Ignore"]; + === If Verification succeeds === + Octavia => "Amphora API" [label="Run Self-test"]; + === If Self-test fails === + Octavia -> Octavia [label="Delete Amphora, retry process"]; + === If Self-test succeeds === + Octavia -> Octavia [label="Add Amphora to standby pool"]; + } +} diff --git a/specs/version0.5/tls-data-security.rst b/specs/version0.5/tls-data-security.rst new file mode 100644 index 0000000000..bc84e097dc --- /dev/null +++ b/specs/version0.5/tls-data-security.rst @@ -0,0 +1,164 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +============================== +TLS Data Security and Barbican +============================== +Launchpad blueprint: + +https://blueprints.launchpad.net/octavia/+spec/tls-data-security + +Octavia will have some need of secure storage for TLS related data. This BP is +intended to identify all of the data that needs secure storage, or any other +interaction that will require the use of Barbican or another secure solution. + +Problem description +=================== +1. Octavia will support TLS Termination (including SNI), which will require us +to store and retrieve certificates and private keys from a secure repository. + +2. Octavia will communicate with its Amphorae using TLS, so each Amphora +will need a certificate for the controller to validate. + +3. Octavia will need TLS data for exposing its own API via HTTPS. + +Proposed change +=============== +The initial supported implementation for TLS related functions will be +Barbican, but the interface will be generic such that other implementations +could be created later. + +.. seqdiag:: tls-data-security-1.diag + +1. Create a CertificateManager interface for storing and retrieving certificate +and private key pairs (and intermediate certs / private key passphrase). +Users will pass their TLS data to Octavia in the form of a certificate_id, +which is a reference to their data in some secure service. Octavia will store +that certificate_id for each Listener/SNI and will retrieve the data when +necessary. (Barbican specific: users will need to add Octavia's user account as +an authorized user on the Container and all Secrets [1] so we catch fetch the +data on their behalf.) + +We will need to validate the certificate data (including key and intermediates) +when we initially receive it, and will assume that it remains unchanged for +the lifespan of the LB (in Barbican the data is immutable so this is a safe +assumption, I do not know how well this will work for other services). In the +case of invalid TLS data, we will reject the request with a 400 (if it is an +initial create) or else put the LB into ERROR status (if it is on a failover +event or during some other non-interactive scenario). + +.. seqdiag:: tls-data-security-2.diag + +2. Create a CertificateGenerator interface to generate certificates from CSRs. +When an Amphora spins up, it will generate its own private key and CSR, then +contact the controller and request a signed certificate. The controller will +cause one to be generated [2] and return it to the Amphora (syncronous), which +will configure the Amphora API to listen using that certificate. All future +communications with the Amphora will do client certificate validation based on +our (private) certificate authority. + +If we are unable to generate a certificate for the Amphora, we will respond +with a 503 and the Amphora will be expected to wait some configurable retry +period before trying again. + +(The CertificateManager and CertificateGenerator interfaces are separate +because while Barbican can perform both functions, future implementations +may need to use two distinct services to achieve both.) + +3. The key/cert for the main Octavia API/controller should be maintained +manually by the server operators using whatever configuration management +they choose. We should not need to use a specific external repo for this. +The trusted CA Cert will also need to be retrieved from barbican and manually +loaded in the config. + +Alternatives +------------ +We could skip the interface and just use Barbican directly, but that would be +diverging from what seems to be the accepted Openstack model for Secret Store +integration. + +We could also store everything locally or in the DB, but that isn't a real +option for production systems because it is incredibly insecure (though there +will be a "dummy driver" that operates this way for development purposes). + +Data model impact +----------------- +Nothing new, the models for this should already be in place. Some of the +columns/classes might need to be renamed more generically (currently there is +a tls_container_id column, which would become tls_certificate_id to be more +generic). + +REST API impact +--------------- +There will need to be an API resource in the controller for the Amphora to +use when requesting a certificate. All further API based communication with +the Amphora will take place over HTTPS and validate the certificate of +both the server and the client. + +Security impact +--------------- +Using Barbican is considered secure. + +Notifications impact +-------------------- +None + +Other end user impact +--------------------- +None + +Performance Impact +------------------ +Adding an external touchpoint (a certificate signing service) to the Amphora +spin-up workflow will increase the average time for readying an Amphora. This +shouldn't be a huge problem if the standby-pool size is sufficient for the +particular deployment. + +Other deployer impact +--------------------- +None + +Developer impact +---------------- +None + +Implementation +============== + +Assignee(s) +----------- +Adam Harwell (adam-harwell) + +Work Items +---------- +1. Create CertificateManager interface. + +2. Create CertificateGenerator interface. + +3. Create BarbicanCertificateManager implementation. + +4. Create BarbicanCertificateGenerator implementation. + +5. Create unit tests! + +Dependencies +============ +This script will depend on the OpenStack Barbican project, including some +features that are still only at the blueprint stage. + +Testing +======= +There will be testing. Yes. + +Documentation Impact +==================== +Documentation changes will be primarily internal. + +References +========== +.. line-block:: + [1] https://review.openstack.org/#/c/127353/ + [2] https://review.openstack.org/#/c/129048/