Include the URL of your launchpad blueprint:
When Fuel was a new project, predefined usernames and passwords were provided for deployment. Securing the services provided by Fuel Master is necessary to meet user expectations. This includes services, such as Cobbler, RabbitMQ, PostgreSQL, rsyslog, and several more. Note that this change does not intersect with the access-control-master-node spec and will not address the Fuel API authentication implementation.
Hardcoded usernames and passwords for every service with no available method to provide strong passwords limits viability in production environments.
Main changes include:
The change is limited to adding a new module to fuelmenu which is not user-facing, plus modifications to Puppet manifests to distribute these passwords, rather than hardcoded passwords.
Passwords could be generated with any tool available, but it would mean that Fuel Master relies on more than one source of information for deployment. The astute.yaml file for deployment provides all information for each service to configure itself with Puppet.
None. The way Nailgun stores data will not be affected in any way.
None. No API will be modified and its configuration will be semantically identical.
Describe any potential security impact on the system. Some of the items to consider include:
The only user impact will be the lack of direct access from outside Fuel Admin network to Fuel Master services (excluding Fuel API).
Regarding new configuration, astute.yaml will contain the following new parameters:
This will take immediate effect after deployment, but requires no manual input.
For continuous integration tests that log directly into any services using predefined usernames and passwords, these credentials need to be parsed from astute.yaml first.
An extra script will be required for upgrading from 5.0 to 5.1 to enable the new manifests to recycle old default passwords. No passwords will be changed (or secured) for deployments that are being upgraded from 5.0. The script will simply populate astute.yaml with the legacy hardcoded passwords.
Feature Lead: raytrac3r Mandatory Design Reviewers: vkuklin Developers: raytrac3r QA: asledzinskiy
Initial phase: * Implement password generation inside fuelmenu.
Second phase: * Implement patch for astute.yaml when performing upgrades from Fuel 5.0.
None. Does coincide with access-control-master-node, but does not actually depend on this blueprint.
The existing deployment tests are adequate.
Acceptance criteria: * Deployment of simple multinode OpenStack succeeds * Diagnostic snapshot works * Health Check works
A note should be added to Fuel User Guide to point users to astute.yaml if he or she requires credentials to the Fuel Master internal services.