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.