Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/SSL"

< Neutron‎ | LBaaS
(Description)
(Rationale)
Line 13: Line 13:
 
Certificates chain should be supported for the Front-End certificate.
 
Certificates chain should be supported for the Front-End certificate.
 
Trusted certificates should be supported for the Back-End certificate.
 
Trusted certificates should be supported for the Back-End certificate.
 +
 +
User will be able to create SSL policies, SSL certificates and SSL trusted keys.
 +
Vip creation will remain with no change
 +
 +
User will be able to associate vip with SSL policy, SSL certificates (1..N) for front-end offload
 +
and SSL trusted keys (0..N) for back-end encryption.
 +
 +
SSL certiicate creation will allow to enter the private key of the certificate if user will check a "remember" check box.
 +
In this case private key will be stored in DB and user will not be required to enter it when associating certificate with a vip.
 +
If user chooses not to store private key in OpenStack DB, private key of the certificate will be requested every time when user
 +
will associate certificate with a vip.
  
 
=== API change ===
 
=== API change ===

Revision as of 09:52, 7 December 2013

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

Rationale

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. Certificates chain should be supported for the Front-End certificate. Trusted certificates should be supported for the Back-End certificate.

User will be able to create SSL policies, SSL certificates and SSL trusted keys. Vip creation will remain with no change

User will be able to associate vip with SSL policy, SSL certificates (1..N) for front-end offload and SSL trusted keys (0..N) for back-end encryption.

SSL certiicate creation will allow to enter the private key of the certificate if user will check a "remember" check box. In this case private key will be stored in DB and user will not be required to enter it when associating certificate with a vip. If user chooses not to store private key in OpenStack DB, private key of the certificate will be requested every time when user will associate certificate with a vip.

API change

No API change

Resources change

LBaaS extension's resource attributes map should be extended with new parameters on the vip object:

Database persistent

* front_end_termination
    Boolean (default=False)
    Mandatory
    Visible
* protocols
    List of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.1, TLSv1.2), default=None
    Mandatory if termination enabled
    Visible if termination enabled
* cipher_suites:
    List of coma-separated values from allowed values list in format 
        <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
    Mandatory if termination enabled
    Visible if termination enabled
* back_end_encryption
    Boolean (default=False)
    Mandatory
    Visible
* back_end_trusted_certs:
    List of certificates including name and PEM-formated certificate body for each one
    NOT Mandatory
    Visible if encryption enabled

Transient (Not stored in DB)

* passphrase (optional, if private key is encrypted)
* public_key (PEM Formatted)
* private_key (PEM Formatted)
* certificate_chain (List of PEM Formatted public keys)

Data model change

  • Vip database entity remains the same.
  • New entity named ssl-policy
ssl-policy-id
protocols (string 64)
cipher_suites (string 512)
  • New entity named ssl-certificate
ssl-certificate-id
public_key (PEM formatted)
passphrase (if private key is encrypted, nullable)
certificate_chain (List of PEM Formatted public keys)
private_key (PEM formatted, nullable)
  • New entity named ssl-trusted-key
ssl-trusted-key-id
key (PEM formatted)
  • New association called vip-ssl-policy-assoc (one policy per vip)
vip-id
ssl-policy-id
status
desc.
  • New association called vip-ssl-certificate-assoc (multiple certificates per vip. certificate may be associated with multiple vips)
vip-id
ssl-certificate-id
status
desc.
  • New association called vip-ssl-trusted-key-assoc (multiple trusted keys per vip. trusted key may be associated with multiple vips)
vip-id
ssl-trusted-key-id
status
desc.

DB Migration

Vip table should be altered with new columns.

New columns of each existing Vip row should be populated with default values:

front_end_termination - False
protocols - None
cipher_suites: None
back_end_termination - False
back_end_trusted_keys: None

CLI Example

neutron lb-vip-create 
--subnet-id <subnet-id> --protocol <protocol> --protocol-port <tcp port> --name <name> --address <address> <pool-id>
--fe-ssl True --ssl-protocols SSLv3, TLSv1, TLSv1.1 --ciphers DES-CBC-SHA, EXP-DES-CBC-SHA
--public-key PUBLIC-KEY --private-key PRIVATE-KEY --passphrase PASSPHRASE --cert-chain INTERMEDIATE-KEY1, INTERMEDIATE-KEY2
--be-encryption True --be-trusted-keys KEY1,KEY2

Implementation Plan

  • Modifying LBaaS Vip resources' attribute map with new parameters
  • Modifying LBaaS Vip DB Model with new parameters
  • Modifying LBaaS Vip DB Model tests to account new parameters if needed
  • Modifying LBaaS HA-Proxy driver to support SSL
  • Update HA-Proxy to version 1.5 {TBD}

Support Matrix

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