Fuel should allow user to deploy OpenStack with TLS for every endpoint, not only for public one.
Current implementation of TLS support for OpenStack endpoints lacks ability to enable TLS for internal or admin endpoints and disable or enable TLS per endpoint.
1. Create additional variables for every TLS endpoint in fuel-library. By default these variables will be unused (fixtures won’t have required data).
None. UI part will be covered by another blueprint.
There are 2 ways of TLS implementation in nailgun. 1. If we implement UI part in main Fuel UI codebase, we need to pass data from UI to task which will generate keys. In this case nailgun must be changed accordingly to have an ability to serialize that data.
2. If we implement UI part in Fuel plugin, we have to implement fetching data from UI by task itself. It seems more reasonable.
User can add a hash to override default TLS values. It should looks like:
use_ssl: horizon: true horizon_public: true horizon_public_hostname: horizon.fuel.local horizon_public_usercert: true horizon_public_certdata: <KeyPairStoredHere> keystone: true keystone_public: true keystone_public_ip: <ip of external keystone> ... keystone_internal: true ... keystone_admin: true ... glance: true glance_public: true ...
New variables that are pulled from Hiera and which allow to override existing TLS data should be added.
Previous releases will be upgraded seamlessly, cause we will introduce new fields to override old ones. Downgrade from existing release to previous one will be unavailable.
All data channels between openstack endpoints will be potentially encrypted. By default TLS for all OpenStack endpoints will be disabled.
User will loose ability to look on data channels between endpoints if they will be encrypted.
Depends on service data rate. For extreme cases performance will be downgraded by 7-10 times (for example, for big images uploading to Glance).
Documentation should be changed as well to reflect introduced changes
Primary assignee: Stanislaw Bogatkin
Mandatory design review: Vladimir Kuklin
In order to verify the quality of new features, automatic system tests have to be expanded.