Difference between revisions of "Neutron/LBaaS/SSL"

Revision as of 07:23, 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

User Experience

TLS Policies Managing

• TLS policies will be stored in neutron schema
• Tenant will be able to "Add" (create), "Delete" (remove) and update TLS policies.
• Front-end TLS offloading is always enabled, therefor no parameter defining it exists

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
* Default front-end supported protocols
* Default front-end supported cipher suites
* Back-end re-encryption is disabled
* Default back-end supported protocols
* Default back-end supported cipher suites
This behavior is hard coded by half (enable offloading, disable re-encryption) in LBaaS Plugin code
and by other half (supported protocols and cipher suites) is configured in 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 (described above).

• Name : text field
• Description : text field
• 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)

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

TLS Certificates Managing

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 out of the Barbican API

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

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 changed 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

Service Port (VIP listener) creation

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

New protocol is proposed - TLS

Service port creation scenarios for each protocol (TCP remain with no change):

• Service port is created with HTTP protocol - no TLS configuration required / available.

Plain traffic is into front-end, L7 rulling available, plain traffic out to back-end server

• Service port is created with HTTPS protocol - no TLS configuration required / available.

Encrypted traffic is into front-end, L7 rulling not available, encrypted traffic out to back-end server

• (new)Service port is created with TLS protocol.

By default, no TLS policy association required, default policy behavior described above 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. Tenant may supply a list of TLS certificates for SNI as well, but does not have to.

Note: Exact way of supporting SNI to be defined.

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-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_protocols (string 32)
  • front_end_cipher_suites (string 512)
  • back_end_enabled (bool)
  • back_end_protocols (string 32)
  • back_end_cipher_suites (string 512)

• service_port_tls_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 TLS certificates associations to service ports

CLI changes

TLS Policy

Note: In case when TLS policies will be neutron DB entities

• neutron tls-policy-create --front-end-termination type=dict enable=true 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 --pass-info type=dict cipher=true bits=true policy name

• neutron tls-policy-update --policy_id --front-end-termination type-dict protocols=TLSv1,TLSv1.1

• neutron tls-policy-delete --policy_id

• neutron tls-policy-list

• neutron tls-policy-show --policy_id

TLS Certificate

TLS certificates management will be available via Barbican CLI

Vip SSL Association

Note: "vip-" might be changed to "listener-" or "service-port-"
Note: Service port TLS settings is atomic CLI command, changing just policy or just certificate(s) is impossible

• neutron vip-tls-setup --vip-id VIP-ID --tls-policy-id my_policy_id --tls-default-certificate type=dict certificate-id=barbican_tls_container_id --tls-sni-certificate type=dict certificate-id=barbican_tls_container_id sni_server_patern=*google.com

or, for associating TLS policy with front-end offloading disabled and back-end re-encryption disabled...

• neutron vip-tls-associate --vip-id VIP-ID --tls-policy-id my_all_disabled_policy_id

Implementation Plan

• Creating new extension called "tls" with new TLS entities
• Add new TLS policy CRUD API to the LBaaS Plugin
• Add new DB entities and associations
• Add unit testing for new TLS extension's resources
• Add 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