Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/SSL"

< Neutron‎ | LBaaS
(Resources change)
(Data model change)
Line 194: Line 194:
 
**tls_policy_name (string 64)
 
**tls_policy_name (string 64)
 
**tls_policy_description (string 256)
 
**tls_policy_description (string 256)
 +
**front_end_offloading (bool)
 
**front_end_protocols (string 32)
 
**front_end_protocols (string 32)
 
**front_end_cipher_suites (string 512)
 
**front_end_cipher_suites (string 512)
**back_end_enabled (bool)
+
**back_end_encryption_enabled (bool)
 
**back_end_protocols (string 32)
 
**back_end_protocols (string 32)
 
**back_end_cipher_suites (string 512)
 
**back_end_cipher_suites (string 512)

Revision as of 13:44, 29 May 2014

Description

Terminating TLS connection on the load balancer and encrypting traffic back to the back end nodes, is a capabilities expected from modern load balancers and incorporated into many applications. This capability enables better certificate management and improved application based load balancing (ex: cookie based persistency, L7 Policies, etc.)

For giving LBaaS TLS termination ability, new extension called TLS will be added.

Rationale

The rational is giving user the ability to do TLS offload on LBaaS.

User should have the ability to configure the LBaaS to offload TLS traffic and encrypt it back while considering specific service ports (VIPs) and SNI

Following are top level requirements

1st phase:

  • Tenant should be able to manage his TLS policies
  • Tenant should be able to manage his certificates and private keys, preferably via Barbican project API.
  • Tenant should be able to apply TLS policy on specific service port (VIP listener)
  • Tenant should be able to associate TLS certificate/s to LBaaS' specific service port and to specific domain as well (SNI)
  • Tenant should be able to configure the LBaaS to re-encrypt the traffic to the back-end


2nd phase:

  • Support certificates chain for front-end certificates
  • Support front-end client authentication and back-end server authentication

Overview

  • Tenant will manage his TLS certificates using Barbican. Certificates will be stored in Barbican secure containers
  • Tenant will manage his TLS policies using Neutron. Policies will be stored in neutron schema
  • In addition to existing HTTP, HTTPS and TCP, new protocol will be added for service port (VIP listener) creation, named TLS
  • For tenant, creating service port with TLS as a protocol means desire to offload incoming encrypted traffic or/and encrypting outgoing traffic to the back-end servers.

While creating service port with TLS protocol:

    • Not necessary to supply TLS policy - default behavior will be implemented, partly configurable in neutron configuration file
      • Front-end TLS offloading enabled, back-end re-encryption disabled - hard coded as a default behavior in code
      • Front-end / Back-end supported protocols and cipher suites are listed in neutron configuration file. Editing allowed, restarting service needed
    • If no policy associated and default behavior will take place - tenant must supply default TLS certificate for front-end offloading
    • If policy associated and it specifies no front-end offloading but back-end re-encryption - tenant must not supply default TLS certificate for front-end offloading
    • SNI certificates are not mandatory to specify


More details below

Neutron LBaaS to Barbican API requirements

  • need API for getting whole TLS certificate container, including private key, by container id
  • need API for getting TLS certificates x.509 certificate

User Experience

TLS Certificates Management

TLS certificates will be store in Barbican certificate containers that contain the TLS certificate itself and its private key. We should also examine the need to perform certificate sign requests using Barbican.

Tenant will be able to create (add), delete (remove) and update TLS certificates using Barbican

Following required for creation:
  • Name : text field
  • Description : text field
  • Certificate : PEM file name
  • Private key: PEM file name (optional)
  • Pass phrase : text field (optional)
"Delete", as usual, preceded by confirmation. Associated certificates are deletion protected
Following may be modified/updated for existing certificate:
  • name
  • description
Note: If changed certificate is associated with one or more service ports (listeners), each back-end service provider (driver) should make any required changes

TLS Policies Management

  • TLS policies will be stored in neutron schema
  • Tenant will be able to "Add" (create), "Delete" (remove) and update TLS policies.


Note: Default TLS policy behavior will be available
In case when service port (VIP listener) should have TLS policy but no TLS policy was defined for it, default behavior will take place:
* Front-end offloading is enabled (hard-coded)
* Default front-end supported protocols (configurable via neutron configuration file)
* Default front-end supported cipher suites (configurable via neutron configuration file)
* Back-end re-encryption is disabled (hard-coded)
* Default back-end supported protocols (configurable via neutron configuration file)
* Default back-end supported cipher suites (configurable via neutron configuration file)


Cipher suites groups will be available: low, medium and high. A tenant will be able to choose one of them or to compile a customized list

Creating TLS policy
Note: Values for all parameters are derived from the default TLS policy behavior (described in overview section).
  • Name : text field
  • Description : text field
  • Enable Front-End offloading : check box (requires default TLS certificate)
  • Enable Back-End encryption : check box
  • Front-End supported protocols : multiple selector (at least one should be selected)
  • Front-End supported cipher suites : Radio button with 4 choices:
    • LOW (OpenSSL LOW ciphers, Hint should show them all)
    • MEDIUM (OpenSSL MEDIUM ciphers, Hint should show them all)
    • HIGH (OpenSSL HIGH ciphers, Hint should show them all)
    • All: (All cipher suites supported by the provider)
  • Back-End supported protocols : multiple selector (at least one should be selected)
  • Back-End supported cipher suites : Radio button with 4 choices (similar to front-end)
Note: Policy with both, front-end offloading and back-end re-encryption, disabled - is invalid
Deleting TLS policy, as usual, preceded by confirmation. Associated policies are deletion protected
Following fields may be modified on policy update:
  • all fields
Note: If changed policy is associated with one or more service ports (VIP listeners), each back-end service provider should perform any required changes

Service Port (VIP listener) creation

Service port (VIP listener) has currently 3 protocols for choice (HTTP, HTTPS, TCP)

New protocol is proposed - TLS, which will be used to address cases of front end or/and back end encryption using certificates and policies.

Service port creation scenarios for TLS:

By default, no TLS policy association required, default policy behavior described in overview section will take place. Tenant may associate TLS policy in order to get different behavior, but does not have to. Tenant must supply a default TLS certificate for front-end offloading if policy enabled front-end offloading. Tenant may supply a list of TLS certificates for SNI as well, but does not have to.


Proposals for SNI certificates list managing

We should decide how we will implement it


1. Ordered list.

Tenant will create list of TLS certificates and be able to control its order.

We guarantee the tenant's order preservation

We treat the list in following steps (until the first match):

  • Scan the list, from first to last (top->bottom) and check if domain name exactly matches certificate's host name
  • Scan the list, from first to last (top->bottom) and check if domain name matches certificate's host name regex
  • Scan the list, from first to last (top->bottom) and check if domain name matches one of certificate's alternative host names
  • No matches found? - use default certificate


2. List of (Certificate, list of (host names/patterns)): Example: ( (amazon_cert_id, [*amazon.com, *amazon1.com]), (acme_cert_id, [acme.com]) )

Tenant will create entries of TLS certificate and list of host name/s or host name patterns for this specific certificate.

We guarantee the tenant's order preservation

We treat the list in following steps (until the first match):

  • Scan the list, from first to last (top->bottom) and check if domain name matches one of host names/patterns
  • No matches found? - use default certificate

Service port (VIP listener) TLS Settings

  • TLS policy and certificates settings are available only for service ports having TLS protocol
  • Removing TLS policy from TLS service port will cause usage of predefined behavior
  • Default TLS certificate for front-end offloading should be defined in order to save the settings

API change

  • TLS policies CRUD will be added to LBaaS plugin API
  • Since TLS offload capability is a core LBaaS capability, service port TLS settings API will be added to the LBaaS plugin

Resources change

  • Service port (VIP listener) resource will be modified with new:
    • TLS policy (optional)
    • Default TLS certificate (optional)
    • Link to SNI certificates list - SNI certificates will be saved as associations to service port, in new associations table


  • TLS policy (new entity)
    • front-end-offloading : bool
    • front-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.1, TLSv1.2), default=None
    • front-end-cipher_suites : list of coma-separated values from allowed values list.
      • Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
    • back-end-encryption : bool
    • back-end-protocols : <similar to front end>
    • back-end-cipher_suites : <similar to front end>

Data model change

  • Service port (VIP listener) entity will be modified with new optional TLS policy and TLS default certificate fields.
    • tls_policy_id (string 36)
    • default_tls-certificate_id (string 36) - Barbican certificate container id


  • tls_policy (new table)
    • tls_policy_id (string 36)
    • tls_policy_name (string 64)
    • tls_policy_description (string 256)
    • front_end_offloading (bool)
    • front_end_protocols (string 32)
    • front_end_cipher_suites (string 512)
    • back_end_encryption_enabled (bool)
    • back_end_protocols (string 32)
    • back_end_cipher_suites (string 512)


  • service_port_sni_certificate_assoc - N:M (new associations table)
    • service_port_id (string 36)
    • tls_certificate_id (string 36)
    • SNI_server_name_pattern (string 255) - optional, depending on chosen way to manage SNI certificates list

DB Migration

DB migration is needed for:

  • Service port new columns - existing rows will be filled by null
  • New table for TLS policies
  • New table for SNI certificates associations to service ports

CLI examples

TLS Policy
  • Tenant creates TLS policy
neutron tls-policy-create --front-end-termination type=dict protocols=SSLv3,TLSv1,TLSv1.1 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA 
--back-end-termination  type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.1 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA my_policy_backend_enabled

New TLS policy named my_policy_backend_enabled created, supporting SSLv3,TLSv1,TLSv1.1 protocols and DES-CBC-SHA,EXP-DES-CBC-SHA cipher suites on front-end, with back-end re-encryption enabled and same supported protocols and cipher suites on back-end


  • Tenant updates my_policy_backend_enabled policy with different protocols (no SSLv3)
neutron tls-policy-update --policy_id my_policy_backend_enabled_ID --front-end-termination type-dict protocols=TLSv1,TLSv1.1 --back-end-termination  type=dict protocols=TLSv1,TLSv1.1
  • Tenant deletes policy my_policy_backend_enabled
neutron tls-policy-delete --policy_id my_policy_backend_enabled_ID
  • Listing policies
neutron tls-policy-list
  • Showing policy
neutron tls-policy-show --policy_id
TLS Certificate

TLS certificates management will be available via Barbican CLI

<To be expanded>

Service port creation with TLS protocol
lb-service-port-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 --tls_default_certificate <barbican certificate container id> 
--name <name> [--address <address>] [-- admin-state-down] [--connection-limit <connection limit>] [--description <description>] [--tenant-id <tenant id>] <pool-id>
[--session-persistence type=dict type=<type>,[cookie_name=<name>]]
Service port TLS Settings
Note: Service port TLS settings is atomic CLI command, changing just policy or just certificate(s) is impossible
  • Setting service port TLS settings
neutron service-port-tls-setup --service-port-id SERVICE-PORT-ID --tls-policy-id my_policy_id 
--default-tls-certificate-id barbican_tls_container_id  --sni-certificates type=list barbican_tls_container_id, barbican_tls_container_id

Implementation Plan

  • Creating new extension called "tls" with new TLS entities
  • implement new TLS policy CRUD API to the LBaaS Plugin
  • Implement changes in DB schema
  • Implement unit testing for new TLS extension's resources
  • Implement unit testing for new TLS DB mixin
  • Make integration with Barbican certificates storage API
  • Modifying LBaaS HA-Proxy driver to support TLS extension
  • Update HA-Proxy to version 1.5 {TBD}

Support Matrix

Provider Protocols Cipher Suites Certificate chain FE client auth. BE auth. SNI
HAProxy 1.5 SSLv3, TLSv1 As OpenSSL Yes No No Yes
Amazon EC2 SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 As OpenSSL No Yes No No
OpenStack SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 As OpenSSL phase 2 phase 2 phase 2 Yes