openstack/octavia
Code Issues Proposed changes

Merge "TLS Data Security Overview"

Browse Source
This commit is contained in:
Jenkins 2014-11-18 21:28:00 +00:00 committed by Gerrit Code Review
commit bae214f23c
3 changed files with 209 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
specs/version0.5/tls-data-security-1.diag Normal file
View File

@ -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"];
}

29
specs/version0.5/tls-data-security-2.diag Normal file
View File

@ -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"];
}
}

164
specs/version0.5/tls-data-security.rst Normal file
View File

@ -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/