Description of problem

There is currently no consolidated security hardening guide available for Red Hat Satellite 6, similar to the Red Hat Ansible Security Automation Guide. Customers are requesting official documentation that outlines security best practices, hardening recommendations, and security automation guidance specific to Satellite 6.

How reproducible

Always.

Is this issue a regression from an earlier version

No.

Actual behavior

Satellite security guidance is fragmented across multiple documents and does not provide a single, structured guide covering security hardening, best practices, and automation use cases.

Expected behavior

Provide an official Red Hat Satellite 6 Security / Security  Guide, similar in structure and scope to the Red Hat Ansible Security Automation Guide, covering:

• Security hardening best practices

• Certificate and authentication management

• RBAC and access control

• Compliance and auditing

---- * Security automation examples

Business Impact / Additional info

Without a centralized security guide, customers face increased operational risk, inconsistent security implementations, and difficulty aligning Satellite deployments with enterprise security standards. A dedicated guide would improve security posture, customer confidence, and adoption of best practices.

Update from Avital Pinnick, Content Strategist, after discussion with stakeholders.

Personae

Security information is relevant for 2 personae, with different requirements. 

These personae might be the same person, in real life, so we must ensure that all the information is easily accessible and can be maintained.

•  Security officer. Needs high-level information about security features that Satellite supports.
  • Target documentation: Security considerations in Planning guide.
• Satellite admin. Needs procedures for implementing security features.
  • Target documentation: Dedicated guides (example: Configuring authentication) and sections in component guides (example: Managing users and roles in Admin guide)

Task scope

• Planning guide:
  • Expand "Security considerations" section to ensure that it describes all relevant security-related features.
  • Add "Additional resources" section with links to procedures that are located in other guides.
• Other guides:
  • No action required. Note: The Admin guide could be better organized. We can look into reorganizing the security procedures as part of the JTBD framework.

Rationale

I think this solution will be simplest to implement and maintain. In my experience, a guide for a generic topic such as "security" tends to become an 'orphan' guide because security is for the entire product, not a single component. (This is the same situation that affects the Planning guide.) Maintenance becomes problematic when a guide does not have a clear-cut owner.

I also want to avoid a situation in which a writer has to decide whether a new feature belongs in "Security" or a component-specific guide. A feature might very well belong to both but we do not want to duplicate content unless there is a very strong business case for doing so.

Linking to the feature from the Planning guide should solve both issues and reduce the maintenance considerably, since only the links in the Planning guide would have to be maintained when new features are documented.