Red Hat provided a Security and Hardening Guide for OSP versions.

The ask is to get an updated version for RHOSO 18.0, covering similar topics and updated to cover the new deployment model.

Feature Overview 

Recreate the hardening guide with RHOSO 18.0 topics and organize other security-related content in more JTBD-appropriate structure in the doc library. 

Goals

In RHOSP 17.1, we had a hardening guide with all the necessary steps to secure the environment after deployment. The overall security topic breakdown was as follows:

• https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/hardening_red_hat_openstack_platform/index
• https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/managing_openstack_identity_resources/index
• https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/integrating_openstack_identity_with_external_user_management_services/index
• https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/managing_secrets_with_the_key_manager_service/index

When the docs team performed the refactoring for RHOSO 18.0, the security topics that were carried over from the previous version landed mostly in the following guides:

• https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/configuring_security_services/index
• https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/performing_security_operations/index
• (Some security-related topics moved to other guides if they were determined to be necessary inside an end-to-end job/story process)

Following field and customer feedback, it seems that the refactoring moved the security topics to guides that are too broad and there is a strong business justification to regroup the hardening-related topics back into a hardening guide.

Another request is to bridge the feature parity gap with hardening-related functionality, however this is out of scope for the docs team and will need engineering-driven features to implement before we can document them. 

Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
…

• Hardening guide is constructed, verified where needed, and published
• Follow-up tickets for engineering-driven feature parity work created and handed over to relevant teams

Out of Scope 

• Feature parity for security functionality (will require separate engineering features/outcomes to track)

Documentation Considerations

• Release note in addition to the hardening guide, to notify customers

Customer Considerations 

Several customers requested this (PM can confirm)

Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone