.. This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode =========================== Secure Fuel Master Services =========================== Include the URL of your launchpad blueprint: https://blueprints.launchpad.net/fuel/+spec/secure-fuel-master-services 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. Problem description =================== Hardcoded usernames and passwords for every service with no available method to provide strong passwords limits viability in production environments. Proposed change =============== Main changes include: * Randomized passwords generated by fuelmenu for supporting services. * Limiting service availabilty to Admin network * Adapt astute.yaml to contain service usernames and passwords 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. Alternatives ------------ 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. Data model impact ----------------- None. The way Nailgun stores data will not be affected in any way. REST API impact --------------- None. No API will be modified and its configuration will be semantically identical. Security impact --------------- Describe any potential security impact on the system. Some of the items to consider include: * Visibility of passwords in astute.yaml may pose a risk, but gaining root access compromises many other services that would be a concern as well. * This change will involve a password generation schema that should be reasonably strong and not predictable. * Not permitting user-provided data ensures stronger passwords for supporting services. Notifications impact -------------------- None. Other end user impact --------------------- The only user impact will be the lack of direct access from outside Fuel Admin network to Fuel Master services (excluding Fuel API). Performance Impact ------------------ None. Other deployer impact --------------------- Regarding new configuration, astute.yaml will contain the following new parameters: * ostf/user * ostf/password * postgres/nailgun_dbname * postgres/nailgun_user * postgres/nailgun_password * postgres/ostf_dbname * postgres/ostf_user * postgres/ostf_password * mcollective/user * mcollective/password * astute/user * astute/password * cobbler/user * cobbler/password 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. Developer impact ---------------- None. Upgrade impact -------------- 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. Implementation ============== Assignee(s) ----------- Primary assignee: raytrac3r Feature Lead: raytrac3r Mandatory Design Reviewers: vkuklin Developers: raytrac3r QA: asledzinskiy Work Items ---------- Initial phase: * Implement password generation inside fuelmenu. * Add service password module to fuelmenu to generate randomized credentials. * Refactor site.pp for each service to use these passwords. Second phase: * Implement patch for astute.yaml when performing upgrades from Fuel 5.0. * Add iptables rules to limit which interfaces expose external access. * (Nice to have) method to update any of these passwords and propagate changes to every service after initial deployment. Dependencies ============ None. Does coincide with access-control-master-node, but does not actually depend on this blueprint. Testing ======= The existing deployment tests are adequate. Acceptance criteria: * Deployment of simple multinode OpenStack succeeds * Diagnostic snapshot works * Health Check works Documentation Impact ==================== 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. References ========== None.