octavia

TLS Data Security Overview

Registered by Stephen Balukoff

Octavia will need to interface with a secure storage engine (Barbican by default) at several different points in the process of delivering load balancing services. These interactions should be well documented (including proper behavior around error scenarios). These touchpoints include:

1. Terminated TLS listeners: Getting certificate / secret information from barbican.
2. Amphorae lifecycle and API: Amphorae will need both a trusted server certificate (for the RESTful amphora-api), and client certificate (for originating requests to the haproxy-amphora-driver RESTful interface on the LB network.
3. haproxy-amphora-driver will need both a trusted client certificate (for originating connections to the amphora API), and server certificate (for its own RESTful API that the amphorae will talk to).

(2 and 3 are needed to accomplish bi-directional authentication and encryption between the haproxy-amphora-driver and the haproxy amphorae.)

Blueprint information

Status:
Not started
Approver:
None
Priority:
Medium
Drafter:
Stephen Balukoff
Direction:
Needs approval
Assignee:
Adam Harwell
Definition:
Approved
Series goal:
None
Implementation:
Not started
Milestone target:
milestone icon 0.5

Related branches

Sprints

Whiteboard

1. TLS Listeners will have an associated ContainerID (default_tls_container_id) which is the link to the Certificate in Barbican. This will need to be fetched.

2. The Amphora-API will generate its own private key and certificate when it spins up, and will send the certificate to the Octavia Controller when it either:
  a) Calls home to announce it has spun up successfully
  b) Is contacted by the Controller during initialization
Which method it uses depends on what we decide for the Amphora spin-up process. This private key will remain local to the Amphora, and will be thrown away with the Amphora if it is trashed, so should not need to be stored externally (so no Barbican interaction is necessary).

3. The Controller-API will have one private key and certificate that will be used globally, which would be generated and set up in Apache/nginx/whatever by the server operator.
This certificate should be included as part of the base image for the Amphora. Also no Barbican interaction necessary.

Gerrit topic: https://review.openstack.org/#q,topic:bp/tls-data-security,n,z

Addressed by: https://review.openstack.org/130659
    TLS Data Security Overview

Addressed by: https://review.openstack.org/131300
    Allow .diag file extensions in spec reviews

Addressed by: https://review.openstack.org/131889
    Support for Certificate data handling

Addressed by: https://review.openstack.org/132578
    Local development implementation for Certificates

Addressed by: https://review.openstack.org/132580
    Barbican implementation for Certificates

Gerrit topic: https://review.openstack.org/#q,topic:133564,n,z

(?)

Work Items

Work items:
Document work-flows and error conditions of all barbican interactions: TODO

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.