Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/SSL"

< Neutron‎ | LBaaS
(→‎SSL Trusted Certificates Managing)
(→‎API change)
 
(201 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
 
=== Description ===
 
=== Description ===
−
Terminating SSL 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.
+
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.)
 
This capability enables better certificate management and improved application based load balancing (ex: cookie based persistency, L7  Policies, etc.)
  
−
For giving LBaaS SSL termination ability, new extension called SSL will be added.
+
For giving LBaaS TLS termination ability, new extension called TLS will be added.
  
−
=== Rationale ===
+
===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, TLS will be added for VIP listener creation
 +
*For tenant, creating VIP listener with TLS as a protocol means desire to offload incoming encrypted traffic or/and encrypting outgoing traffic to the back-end servers.
  
−
The rational is giving user the ability to use SSL on LBaaS.
 
  
−
User should be able to apply SSL certificates on LBaaS and configure SSL on vip, front-end and back-end.
+
*When creating VIP listener 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. This is editable via neutron configuration file
 +
** If no policy associated and default behavior will take place - tenant must supply default TLS certificate for front-end offloading
 +
** If policy associated and the policy disables front-end offloading but enables back-end re-encryption - tenant must not supply default TLS certificate for front-end offloading
 +
** SNI certificates are not mandatory to specify
 +
** SNI certificates list specifying manner and treatment proposals are posted in "Proposals for SNI certificates list specifying and treating" section and should be discussed
 +
* Certificates chain for front-end certificates will be not be supported in this phase
 +
* Front-end client authentication and back-end server authentication will not be supported in this phase
  
−
*Certificates chain should be supported for the Front-End certificate.
 
−
*Trusted certificates should be supported for the Back-End certificate.
 
−
*User should be able to manage SSL policies, SSL front-end certificates and SSL trusted back-end certificates.
 
−
*User should be able to associate vip with SSL policy and SSL certificates for front-end offload,
 
−
and SSL trusted certificates for back-end encryption.
 
−
*User should have a choice to store certificates private keys in OpenStack repository or not.
 
  
−
SSL certificate creation will let the user to enter the private key of the certificate if user will check a "remember" check box.
+
With stated above, following is a description of a basic tenant use case - creating VIP listener with TLS offloading:
−
In this case, private key will be stored encrypted with a key specified in configuration file and user will not be required to enter it when associating certificate with a vip.
+
*Creating VIP listener with TLS as a listener protocol
 +
*Specifying default TLS certificate for front-end offloading by supplying Barbican's TLS certificate container ID
 +
As a result, VIP listener created, offloading encrypted traffic on front-end with default tenant's TLS certificate, not re-encrypting traffic to the back-end.
  
−
If user chooses not to store private key in OpenStack DB, private key of the certificate will be requested every time when user
+
===Neutron LBaaS to Barbican API requirements===
−
will associate certificate with a vip.
+
*need API for getting whole TLS certificate container, including private key, by container id
−
*Even when private key is transient, its transport should be secured.
+
*need API for getting TLS certificates x.509 certificate
  
 
=== User Experience ===
 
=== User Experience ===
−
==== SSL Policies Managing ====
 
−
Under Project tab->Manage Network->Load Balancers->SSL Policies (new tab),
 
−
user will see a table of SSL policies with "Add" and "Delete" buttons, as usual.
 
  
−
Default policy will be available. It will have default set of protocols and cipher suites.
+
==== TLS Certificates Management====
−
User should be able to explore default policy details but should not be able to delete it.
+
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.
  
−
Cipher suites groups will be available, low, medium and high. A user will be able to choose one of them or to compile a customized list
+
Tenant will be able to create (add), delete (remove) and update TLS certificates using Barbican
  
−
On "Add", as usual, form pops-up with:
+
=====Creating TLS certificate (using Barbican)=====
 
*Name : text field
 
*Name : text field
−
*Enable Front-End termination : check box
+
*Description : text field
−
*Front-End supported protocols : multiple selector (at least one should be selected)
+
*Certificate : PEM file name
−
*Front-End supported cipher suites : Radio button with 4 choices:
+
*Private key: PEM file name (optional)
−
** LOW (OpenSSL LOW ciphers, Hint should show them all)
+
*Pass phrase : text field (optional)
−
** MEDIUM (OpenSSL MEDIUM ciphers, Hint should show them all)
+
 
−
** HIGH (OpenSSL HIGH ciphers, Hint should show them all)
+
 
−
** Custom: multiple selector (at least one suite should be selected)
+
===== Deleting TLS certificate (using Barbican)=====
−
*Enable Back-End encryption : check box
+
Preceded by confirmation.
−
*Back-End supported protocols : multiple selector (at least one should be selected)
+
Certificates that are used by VIP listener/s can not be deleted
−
*Back-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)
 
−
** Custom: multiple selector (at least one suite should be selected)
 
−
*Pass info
 
−
**Cipher : check box
 
−
**Version : check box
 
−
**Bits : check box
 
−
**Frontend – add “Front-End-Https:” to headers : check box
 
  
−
Note: Front-End or Back-End or both must be configured to SAVE.
+
=====Updating TLS certificate (using Brbican)=====
 +
*Only name and description may be modified
  
−
On "Delete", as usual, confirmation. Associated policies are deletion protected.
+
Note: If changed certificate is associated with VIP listener(s), each back-end service provider (driver) should make any required changes
  
−
On Actions->"Edit Policy" button, form opens-up with all fields allowed for change
+
==== TLS Policies Management====
  
−
On Actions column->"More" button contains delete option only
+
*TLS policies will be stored in neutron schema
 +
*Tenant will be able to "Add" (create), "Delete" (remove) and update TLS policies.
 +
*Default TLS policy behavior description:
 +
**Front-end offloading is enabled (hard-coded)
 +
**Default front-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
 +
**Default front-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
 +
**Back-end re-encryption is disabled (hard-coded)
 +
**Default back-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
 +
**Default back-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
 +
*The proposal is to use OpenSSL cipher suite groups (all, low, medium, high) as options to define cipher suites
 +
https://www.openssl.org/docs/apps/ciphers.html
 +
*('''TBD''') We may also give tenant an option to compile his own cipher suite group
  
−
==== SSL Certificates Managing ====
+
=====Creating TLS policy=====
−
Under Project tab->Manage Network->SSL Certificates (new),
+
Note:
−
user will see a table of SSL certificates with "Add" and "Delete" buttons, as usual.
+
1.Policy with both, front-end offloading and back-end re-encryption, disabled - is '''invalid'''
 +
2.When creating TLS policy ,default values for all parameters are derived from the
 +
  default TLS policy behavior (described above).
  
−
On "Add", as usual, form pops-up with:
 
 
*Name : text field
 
*Name : text field
−
*Certificate : text field
+
*Description : text field
−
*Pass phrase : text field
+
*Enable Front-End offloading : check box (requires default TLS certificate specification)
−
*Certificate chain : text field
+
*Enable Back-End encryption : check box
−
*Persist private key : check box
+
*Front-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
−
  (Hint: If checked, certificate private key will be stored in OpenStack repository
+
*Front-End supported cipher suites : Radio button with 4 choices:
−
  and will not be requested when associating the certificate to a vip.  
+
** ALL: (OpenSSL ALL ciphers group )
−
  If unchecked, certificate private key will be requested each time
+
** LOW (OpenSSL LOW ciphers group)
−
  when certificate will be associated to a vip)
+
** MEDIUM (OpenSSL MEDIUM ciphers group)
 +
** HIGH (OpenSSL HIGH ciphers group)
 +
*Back-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
 +
*Back-End supported cipher suites : Radio button with 4 choices (similar to front-end)
  
−
*Private key : text field (disabled if "persist private key" check box is not checked)
 
  
−
Note: If private key persistence is enabled, private key must be supplied.
+
=====Deleting TLS policy=====
 +
As usual, preceded by confirmation.
 +
Policy that is used by VIP listener(s) can not be deleted
  
−
On "Delete", as usual, confirmation. Associated certificates are deletion protected.
+
=====Updating TLS policy=====
 +
*Only front-end and back-end protocols and cipher suite groups may be modified
 +
*Changing front-end offloading and back-end re-encryption functionality is not supported
  
−
On Actions->"Edit Certificate" button, form opens-up with all fields allowed for change
+
Note: If changed policy is associated with VIP listener(s), each back-end service provider should perform any required changes
  
−
On Actions column->"More" button contains delete option only
+
==== VIP listener creation ====
  
−
==== SSL Trusted Certificates Managing ====
+
VIP listener has currently 3 protocols for choice (HTTP, HTTPS, TCP)
−
Under Project tab->Manage Network->Load Balancers->SSL Trusted Certificates(new tab),
+
New protocol is proposed - '''TLS''', which will be used to address cases of front end or/and back end encryption using certificates and policies.
−
user will see a table of SSL trusted certificates with "Add" and "Delete" buttons, as usual.
 
  
−
On "Add", as usual, form pops-up with:
+
=====VIP listener creation scenarios for TLS=====
−
*Name : text field
+
 
−
*Certificate : text field
+
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.
 +
 
 +
 
 +
=====Proposal for SNI certificates specifying and its treating by LBaaS provider=====
 +
 
 +
 
 +
1. Ordered list of certificates.
  
 +
Tenant will create list of TLS certificates and be able to control its order.
  
−
On "Delete", as usual, confirmation. Associated certificates are deletion protected.
+
Choosing TLS certificate for incoming traffic offload will be done in following steps (until the first match):
  
−
On Actions->"Edit Certificate" button, form opens-up with all fields allowed for change
+
*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
  
−
On Actions column->"More" button contains delete option only
 
  
−
==== Vip SSL Association ====
+
2. List of certificates
−
'''Important Note: Associating and disassociating SSL for a vip are atomic actions.'''
 
−
'''Saving the vip SSL association will require re-entering all missing certificate private keys.'''
 
−
'''SSL disassociating of a vip will remove all associations with policy and certificates. This is relevant for UI and CLI.'''
 
  
−
On Project->Load Balancers screen, For each pool, "More" button->VIP SSL association(new) option, new form opens-up.
+
Tenant will create list of TLS certificates.
  
−
Single SSL policy may be selected from policies table, containing selection check box and policy name.
+
*Choosing TLS certificate for incoming traffic offload will be done by scanning the list until the first match
−
User will also be able to press the "Add New" button and get the SSL Policy addition form.
+
*No matches found? - use default certificate
  
−
Depending on policy, if front-end termination is enabled, SSL certificates table will be enabled for choosing certificates.
 
  
−
SSL certificates table contains certificate name, and private key text box.
+
3. List of (Certificate, list of (host names/patterns)):
−
Private key text box contains the key and is disabled if private key is persistent in OpenStack repository.
+
Example: '''(''' (amazon_cert_id, [*amazon.com, *amazon1.com]), (acme_cert_id, [acme.com]) ''')'''
−
Private key text box is editable if private key is not persistent. User must supply it.
 
−
At least one certificate must be selected.
 
−
Also, "Add New" button will present. Pressing it will open the SSL certificate form.|
 
  
−
Depending on policy, if back-end encryption is enabled, SSL trusted certificates table will be enabled for choosing keys.
+
Tenant will create entries of TLS certificate and list of host name/s or host name patterns for this specific certificate.
  
−
SSL trusted certificates table contains selection check box and key name.
+
Choosing TLS certificate for incoming traffic offload will be done in following steps (until the first match):
−
User may select none or multiple keys.
 
−
Also, "Add New" button will present. Pressing it will open the SSL trusted certificate form.|
 
  
−
*'''To save an association:'''
+
*Scan the list, from first to last (top->bottom) and check if domain name matches one of host names/patterns
−
SSL policy must be selected. If front-end termination is enabled, at least one SSL certificate must be selected.
+
*No matches found? - use default certificate
 +
Note: this can not be supported by Radware LBaaS provider
  
−
*'''To remove association:'''
+
==== VIP listener (with TLS protocol) updating ====
−
SSL policy must not be selected. All other fields will be disabled.
+
*TLS policy and certificates settings are available only for VIP listeners having TLS as a protocol
 +
*Changing TLS Policy for existing VIP listener is proposed to be deprecated because
 +
different policy may specify different behavior for front-end offloading and/or back-end re-encryption.
 +
This will require radical re-configuration of provider's back-end system, which seems to be not justified for this use case.
 +
Tenant, probably, should create new VIP listener with different TLS front-end offloading and back-end re-encryption settings.
  
 
=== API change ===
 
=== API change ===
−
*Vip CRUD API of the LBaaS plugin will not be changed.
+
*TLS policies CRUD will be added to LBaaS plugin API
−
*New extension named "ssl" will be added, including certificate resource
+
*Since TLS offload functionality is a core LBaaS capability, VIP listener TLS settings API will be merged into the existing LBaaS plugin API
−
*New SSL policy and trusted key entities will be added to the LBaaS service
 
−
*Vip SSL association API should be added to the LBaaS plugin
 
  
 
=== Resources change ===
 
=== Resources change ===
−
*vip resource remains the same
 
  
−
*SSL policy (new)
+
*VIP listener resource will be modified with new:
−
**front-end-termination : bool
+
**TLS policy (optional)
−
**front-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.1, TLSv1.2), default=None
+
**Default TLS certificate (optional)
−
**front-end-cipher_suites : list of coma-separated values from allowed values list.
+
**Associations link to SNI certificates list - SNI certificates will be saved 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.2), default=None
 +
**front-end-cipher_suites : list of coma-separated values
 
***Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
 
***Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
 
**back-end-encryption : bool
 
**back-end-encryption : bool
−
**back-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.1, TLSv1.2), default=None
+
**back-end-protocols : <same format as front end>
−
**back-end-cipher_suites : list of coma-separated values from allowed values list.
+
**back-end-cipher_suites : <same format as front end>
−
***Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
 
−
**pass-info : list of coma-separated values from allowed values list (cipher, protocol, bits, front-end)
 
−
 
 
−
* SSL certificate (new)
 
−
**certificate : PEM-formatted string
 
−
**pass_phrase : not mandatory string
 
−
**private_key : PEM-formatted string, not mandatory
 
−
**certificate_chain : list of PEM-formatted public keys, not mandatory
 
−
 
 
−
* SSL trusted certificate (new)
 
−
**public_key : PEM-formatted string
 
  
 
=== Data model change ===
 
=== Data model change ===
−
*vip entity will be associated with SSL policy, SSL certificate and SSL trusted key entities.
 
  
−
*ssl_policy (new)
+
*VIP listener entity will be modified with new optional TLS policy and TLS default certificate fields.
−
ssl_policy_id (string 36)
+
**tls_policy_id (string 36)
−
ssl_policy_name (string 64)
+
**default_tls-certificate_id (string 36) - Barbican's certificate container id
−
front_end_enabled (bool)
 
−
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)
 
−
pass_info (string 64)
 
  
−
*ssl_certificate (new)
 
−
ssl-certificate_id (string 36)
 
−
ssl-certificate-name (string 64)
 
−
certificate (string 4096)
 
−
pass_phrase (string 64)
 
−
certificate_chain (string 20480)
 
−
private_key (string 4096)
 
  
−
*ssl_trusted_key (new)
+
*tls_policy (new table)
−
ssl_trusted_key_id (string 36)
+
**tls_policy_id (string 36)
−
ssl_trusted_key_name (string 64)
+
**tls_policy_name (string 64)
−
key (string 4096)
+
**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)
  
−
*vip_ssl_policy_assoc (new, one policy per vip)
 
−
vip_id (string 36)
 
−
ssl_policy_id (string 36)
 
−
status (string 16)
 
−
desc (string 255)
 
  
−
*vip_ssl_certificate_assoc (new, multiple certificates per vip. certificate may be associated with multiple vips)
+
*vip_listener_sni_certificate_assoc - N:M (new associations table)
−
vip_id (string 36)
+
**vip_listener_id (string 36)
−
ssl_certificate_id (string 36)
+
**tls_certificate_id (string 36)
−
status (string 16)
 
−
desc (string 255)
 
−
 
 
−
*vip_ssl_trusted_certificate_assoc (new, multiple trusted keys per vip. trusted key may be associated with multiple vips)
 
−
vip_id (string 36)
 
−
ssl_trusted_key_id (string 36)
 
−
status (string 16)
 
−
desc (string 255)
 
  
 
=== DB Migration ===
 
=== DB Migration ===
  
−
No DB migration is needed
+
DB migration is needed for:
−
 
+
*VIP listener new columns - existing rows will be filled by null
−
=== CLI changes ===
+
*New table for TLS policies
−
 
+
*New table for SNI certificates associations to VIP listeners
−
===== SSL Policy =====
 
−
*neutron '''ssl-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 '''ssl-policy-update''' --policy_id --front-end-termination type-dict protocols=TLSv1,TLSv1.1
 
  
−
*neutron '''ssl-policy-delete''' --policy_id
+
=== CLI examples ===
  
−
*neutron '''ssl-policy-list'''
+
*'''VIP listener creation''' with TLS protocol (default behavior)
  
−
*neutron '''ssl-policy-show''' --policy_id
+
lb-vip-listener-create --subnet-id <subnet-id> '''--protocol TLS''' --protocol-port 443
 +
'''--tls_default_certificate <barbican certificate container id>'''  
 +
--name <name> [--address <address>] ...<usual CLI options>
  
−
===== SSL Certificate =====
+
*'''VIP listener creation''' with TLS protocol and SNI certificates list (with TLS policy, front-end offloading enabled, back-end re-encryption enabled)
−
*neutron '''ssl-certificate-create''' --public-key CERTIFICATE-FILE <--private-key PRIVATE-KEY-FILE> <--passphrase PASSPHRASE> <--cert-chain INTERMEDIATE-KEY-FILE-1, INTERMEDIATE-KEY-FILE-2> '''certificate name'''
 
  
−
*neutron '''ssl-certificate-update''' --certificate-id --cert-chain INTERMEDIATE-KEY-FILE-1, INTERMEDIATE-KEY-FILE-2, INTERMEDIATE-KEY-FILE-3
+
lb-vip-listener-create --subnet-id <subnet-id> '''--protocol TLS''' --protocol-port 443
 +
'''--tls_policy policy_with_front_end_offloading_enabled_id --tls_default_certificate <barbican certificate container id>'''
 +
'''--tls_sni_certificates certificate_1, certificate_2, certificate_3'''
 +
--name <name> [--address <address>] ...<usual CLI options>
  
−
*neutron '''ssl-certificate-delete''' --certificate_id
+
*'''VIP listener creation''' with TLS protocol (with TLS policy, front-end offloading disabled, back-end re-encryption enabled)
  
−
*neutron '''ssl-certificate-list'''
+
lb-vip-listener-create --subnet-id <subnet-id> '''--protocol TLS''' --protocol-port 443
 +
'''--tls_policy policy_with_front_end_offloading_disabled_id'''
 +
--name <name> [--address <address>] ...<usual CLI options>
  
−
*neutron '''ssl-certificate-show''' --certificate_id
+
*'''TLS policy creation''' (both, front-end offloading and back-end re-encryption enabled)
 +
lb-tls-policy-create --front-end-termination type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ...
 +
--back-end-termination  type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ...
 +
'''MY_POLICY'''
  
−
===== SSL Trusted Certificate =====
+
−
*neutron '''ssl-trusted-certificate-create''' --key PUBLIC-KEY-FILE '''key name'''
+
*'''Updating MY_POLICY policy with different protocols (no SSLv3)'''
 +
lb-tls-policy-update''' --policy_id MY_POLICY_ID --front-end-termination type-dict protocols=TLSv1,TLSv1.2 --back-end-termination  type=dict protocols=TLSv1,TLSv1.1
  
−
*neutron '''ssl-trusted-certificate-update''' --key-id --key PUBLIC-KEY-FILE
+
*'''Deleting MY_POLICY'''
 +
lb-tls-policy-delete''' --policy_id MY_POLICY_ID
  
−
*neutron '''ssl-trusted-certificate-delete''' --key-id
+
*'''Listing policies'''
 +
lb-tls-policy-list'''
  
−
*neutron '''ssl-trusted-certificate-list'''
+
*'''Showing policy'''
 +
lb-tls-policy-show''' --policy_id
  
−
*neutron '''ssl-trusted-certificate-show''' --key_id
+
TLS certificates management will be available via Barbican CLI
  
−
===== Vip SSL Association =====
+
<To be expanded>
−
*neutron '''vip-ssl-associate''' --vip-id VIP-ID --ssl-policy-id my_policy_id --ssl-certificate type=dict certificate-id=google_cert_id private-key=PRIVATE-KEY-FILE-1 --ssl-trusted-certificate type=dict cert-id=KEY-ID-1
 
−
*neutron '''vip-ssl-disassociate''' --vip-id VIP-ID
 
−
TODO: List of certificates and trusted keys should be supported
 
  
 
=== Implementation Plan ===
 
=== Implementation Plan ===
  
−
* Creating new extension called "ssl" with SSL certificate and trusted key new entities
+
* Creating new extension called "tls" with new TLS entities
−
* Add new SSL entities CRUD API to the LBaaS Plugin
+
* implement new TLS policy CRUD API to the LBaaS Plugin
−
* Add new DB entities and associations
+
* Implement changes in DB schema
−
* Add unit testing for SSL functionality
+
* Implement unit testing for new TLS extension's resources
−
* Modifying LBaaS HA-Proxy driver to support SSL extension
+
* 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}
 
* Update HA-Proxy to version 1.5 {TBD}
  
Line 267: Line 267:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Provider !! Protocols !! Cipher Suites !! Certificate chain !! FE client auth. !! BE trusted keys !! BE client cert. !! SNI
+
! Provider !! Protocols !! Cipher Suites !! Certificate chain !! FE client auth. !! BE auth. !! SNI
 
|-
 
|-
−
| HAProxy 1.5 || SSLv3, TLSv1 || As OpenSSL || Yes || Yes || No ||  No || Yes
+
| HAProxy 1.5 || SSLv3, TLSv1 || As OpenSSL || Yes || No ||  No || Yes
 
|-
 
|-
−
| Amazon EC2 || SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 || As OpenSSL || Yes || No || Yes || No || No
+
| 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 || Yes || No || Yes || No || Yes
+
| OpenStack || SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 || As OpenSSL || phase 2 || phase 2 || phase 2 || Yes
 
|}
 
|}

Latest revision as of 11:15, 30 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.

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, TLS will be added for VIP listener creation
  • For tenant, creating VIP listener with TLS as a protocol means desire to offload incoming encrypted traffic or/and encrypting outgoing traffic to the back-end servers.


  • When creating VIP listener 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. This is editable via neutron configuration file
    • If no policy associated and default behavior will take place - tenant must supply default TLS certificate for front-end offloading
    • If policy associated and the policy disables front-end offloading but enables back-end re-encryption - tenant must not supply default TLS certificate for front-end offloading
    • SNI certificates are not mandatory to specify
    • SNI certificates list specifying manner and treatment proposals are posted in "Proposals for SNI certificates list specifying and treating" section and should be discussed
  • Certificates chain for front-end certificates will be not be supported in this phase
  • Front-end client authentication and back-end server authentication will not be supported in this phase


With stated above, following is a description of a basic tenant use case - creating VIP listener with TLS offloading:

  • Creating VIP listener with TLS as a listener protocol
  • Specifying default TLS certificate for front-end offloading by supplying Barbican's TLS certificate container ID

As a result, VIP listener created, offloading encrypted traffic on front-end with default tenant's TLS certificate, not re-encrypting traffic to the back-end.

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

Creating TLS certificate (using Barbican)
  • Name : text field
  • Description : text field
  • Certificate : PEM file name
  • Private key: PEM file name (optional)
  • Pass phrase : text field (optional)


Deleting TLS certificate (using Barbican)

Preceded by confirmation. Certificates that are used by VIP listener/s can not be deleted

Updating TLS certificate (using Brbican)
  • Only name and description may be modified
Note: If changed certificate is associated with VIP listener(s), 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.
  • Default TLS policy behavior description:
    • Front-end offloading is enabled (hard-coded)
    • Default front-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
    • Default front-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
    • Back-end re-encryption is disabled (hard-coded)
    • Default back-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
    • Default back-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
  • The proposal is to use OpenSSL cipher suite groups (all, low, medium, high) as options to define cipher suites

https://www.openssl.org/docs/apps/ciphers.html

  • (TBD) We may also give tenant an option to compile his own cipher suite group
Creating TLS policy
Note: 
1.Policy with both, front-end offloading and back-end re-encryption, disabled - is invalid
2.When creating TLS policy ,default values for all parameters are derived from the 
 default TLS policy behavior (described above).
  • Name : text field
  • Description : text field
  • Enable Front-End offloading : check box (requires default TLS certificate specification)
  • Enable Back-End encryption : check box
  • Front-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
  • Front-End supported cipher suites : Radio button with 4 choices:
    • ALL: (OpenSSL ALL ciphers group )
    • LOW (OpenSSL LOW ciphers group)
    • MEDIUM (OpenSSL MEDIUM ciphers group)
    • HIGH (OpenSSL HIGH ciphers group)
  • Back-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), 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. Policy that is used by VIP listener(s) can not be deleted

Updating TLS policy
  • Only front-end and back-end protocols and cipher suite groups may be modified
  • Changing front-end offloading and back-end re-encryption functionality is not supported
Note: If changed policy is associated with VIP listener(s), each back-end service provider should perform any required changes

VIP listener creation

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.

VIP listener 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.


Proposal for SNI certificates specifying and its treating by LBaaS provider

1. Ordered list of certificates.

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

Choosing TLS certificate for incoming traffic offload will be done 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 certificates

Tenant will create list of TLS certificates.

  • Choosing TLS certificate for incoming traffic offload will be done by scanning the list until the first match
  • No matches found? - use default certificate


3. 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.

Choosing TLS certificate for incoming traffic offload will be done 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
Note: this can not be supported by Radware LBaaS provider

VIP listener (with TLS protocol) updating

  • TLS policy and certificates settings are available only for VIP listeners having TLS as a protocol
  • Changing TLS Policy for existing VIP listener is proposed to be deprecated because

different policy may specify different behavior for front-end offloading and/or back-end re-encryption. This will require radical re-configuration of provider's back-end system, which seems to be not justified for this use case. Tenant, probably, should create new VIP listener with different TLS front-end offloading and back-end re-encryption settings.

API change

  • TLS policies CRUD will be added to LBaaS plugin API
  • Since TLS offload functionality is a core LBaaS capability, VIP listener TLS settings API will be merged into the existing LBaaS plugin API

Resources change

  • VIP listener resource will be modified with new:
    • TLS policy (optional)
    • Default TLS certificate (optional)
    • Associations link to SNI certificates list - SNI certificates will be saved 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.2), default=None
    • front-end-cipher_suites : list of coma-separated values
      • Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
    • back-end-encryption : bool
    • back-end-protocols : <same format as front end>
    • back-end-cipher_suites : <same format as front end>

Data model change

  • 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's 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)


  • vip_listener_sni_certificate_assoc - N:M (new associations table)
    • vip_listener_id (string 36)
    • tls_certificate_id (string 36)

DB Migration

DB migration is needed for:

  • VIP listener new columns - existing rows will be filled by null
  • New table for TLS policies
  • New table for SNI certificates associations to VIP listeners

CLI examples

  • VIP listener creation with TLS protocol (default behavior)
lb-vip-listener-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 
--tls_default_certificate <barbican certificate container id> 
--name <name> [--address <address>] ...<usual CLI options>
  • VIP listener creation with TLS protocol and SNI certificates list (with TLS policy, front-end offloading enabled, back-end re-encryption enabled)
lb-vip-listener-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 
--tls_policy policy_with_front_end_offloading_enabled_id --tls_default_certificate <barbican certificate container id>
--tls_sni_certificates certificate_1, certificate_2, certificate_3
--name <name> [--address <address>] ...<usual CLI options>
  • VIP listener creation with TLS protocol (with TLS policy, front-end offloading disabled, back-end re-encryption enabled)
lb-vip-listener-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 
--tls_policy policy_with_front_end_offloading_disabled_id
--name <name> [--address <address>] ...<usual CLI options>
  • TLS policy creation (both, front-end offloading and back-end re-encryption enabled)
lb-tls-policy-create --front-end-termination type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ... 
--back-end-termination  type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ...
MY_POLICY


  • Updating MY_POLICY policy with different protocols (no SSLv3)
lb-tls-policy-update --policy_id MY_POLICY_ID --front-end-termination type-dict protocols=TLSv1,TLSv1.2 --back-end-termination  type=dict protocols=TLSv1,TLSv1.1
  • Deleting MY_POLICY
lb-tls-policy-delete --policy_id MY_POLICY_ID
  • Listing policies
lb-tls-policy-list
  • Showing policy
lb-tls-policy-show --policy_id

TLS certificates management will be available via Barbican CLI

<To be expanded>

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
Retrieved from "https://wiki.openstack.org/w/index.php?title=Neutron/LBaaS/SSL&oldid=54284"