Merge "TLS Data Security Overview"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
bae214f23c
|
|
@ -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"];
|
||||
}
|
||||
|
|
@ -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"];
|
||||
}
|
||||
}
|
||||
|
|
@ -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/
|
||||
Loading…
Reference in New Issue