Revision of hardening guide

Corrections

Document how to secure and harden AAP

https://issues.redhat.com/browse/AAP-32887

downstream/modules/aap-hardening/con-credential-management-planning.adoc

@@ -7,7 +7,7 @@
 
 [role="_abstract"]
 
-{PlatformNameStart} uses credentials to authenticate requests to jobs against machines, synchronize with inventory sources, and import project content from a version control system. {ControllerNameStart} manages three sets of secrets:
+{PlatformName} uses credentials to authenticate requests to jobs against machines, synchronize with inventory sources, and import project content from a version control system. {ControllerNameStart} manages three sets of secrets:
 
 * User passwords for *local automation controller users*. See the xref:con-user-authentication-planning_{context}[User Authentication Planning] section of this guide for additional details.
 * Secrets for automation controller *operational use* (database password, message bus password, and so on).

downstream/modules/aap-hardening/con-install-secure-host.adoc

@@ -7,9 +7,12 @@
 
 [role="_abstract"]
 
-The {PlatformNameShort} installer can be run from one of the infrastructure servers, such as an {ControllerName}, or from an external system that has SSH access to the {PlatformNameShort} infrastructure servers. The {PlatformNameShort} installer is also used not just for installation, but for subsequent day-two operations, such as backup and restore, as well as upgrades. This guide recommends performing installation and day-two operations from a dedicated external server, hereafter referred to as the installation host. Doing so eliminates the need to log in to one of the infrastructure servers to run these functions. The installation host must only be used for management of {PlatformNameShort} and must not run any other services or software.
+The {PlatformNameShort} installer can be run from one of the infrastructure servers, such as an {ControllerName}, or from an external system that has SSH access to the {PlatformNameShort} infrastructure servers. 
+The {PlatformNameShort} installer is also used not just for installation, but for subsequent day-two operations, such as backup and restore, as well as upgrades. 
+This guide recommends performing installation and day-two operations from a dedicated external server, hereafter referred to as the installation host. 
+Doing so eliminates the need to log in to one of the infrastructure servers to run these functions. The installation host must only be used for management of {PlatformNameShort} and must not run any other services or software.
 
-The installation host must be a {RHEL} server that has been installed and configured in accordance with link:{BaseURL}/red_hat_enterprise_linux/8/html/security_hardening/index[Security hardening for Red Hat Enterprise Linux] and any security profile requirements relevant to your organization (CIS, STIG, and so on). 
+The installation host must be a {RHEL} server that has been installed and configured in accordance with link:{BaseURL}/red_hat_enterprise_linux/9/html/security_hardening/index[Security hardening for Red Hat Enterprise Linux] and any security profile requirements relevant to your organization (CIS, STIG, and so on). 
 Obtain the {PlatformNameShort} installer as described in the link:{URLPlanningGuide}/choosing_and_obtaining_a_red_hat_ansible_automation_platform_installer[Planning your installation], and create the installer inventory file as described in the link:{URLInstallationGuide}/assembly-platform-install-scenario#proc-editing-installer-inventory-file_platform-install-scenario[Editing the Red Hat Ansible Automation Platform installer inventory file]. 
 This inventory file is used for upgrades, adding infrastructure components, and day-two operations by the installer, so preserve the file after installation for future operational use.
 

downstream/modules/aap-hardening/con-installation.adoc

@@ -7,4 +7,6 @@
 
 [role="_abstract"]
 
-There are installation-time decisions that affect the security posture of {PlatformNameShort}. The installation process includes setting a number of variables, some of which are relevant to the hardening of the {PlatformNameShort} infrastructure. Before installing {PlatformNameShort}, consider the guidance in the installation section of this guide.
+There are installation-time decisions that affect the security posture of {PlatformNameShort}. 
+The installation process includes setting a number of variables, some of which are relevant to the hardening of the {PlatformNameShort} infrastructure. 
+Before installing {PlatformNameShort}, consider the guidance in the installation section of this guide.

downstream/modules/aap-hardening/con-logging-log-capture.adoc

@@ -8,15 +8,21 @@
 [role="_abstract"]
 
 Visibility and analytics is an important pillar of Enterprise Security and Zero Trust Architecture. 
-Logging is key to capturing actions and auditing. You can manage logging and auditing by using the built-in audit support described in the link:{BaseURL}/red_hat_enterprise_linux/9/html/security_hardening/auditing-the-system_security-hardening[Auditing the system] section of the Security hardening for {RHEL} guide. Controller's built-in logging and activity stream support {ControllerName} logs all changes within {ControllerName} and automation logs for auditing purposes. 
+Logging is key to capturing actions and auditing. 
+You can manage logging and auditing by using the built-in audit support described in the link:{BaseURL}/red_hat_enterprise_linux/9/html/security_hardening/auditing-the-system_security-hardening[Auditing the system] section of the Security hardening for {RHEL} guide. 
+{ControllerNameStart}'s built-in logging and activity stream support {ControllerName} logs all changes within {ControllerName} and automation logs for auditing purposes. 
 More detailed information is available in the link:{URLControllerAdminGuid}/assembly-controller-logging-aggregation[Logging and Aggregation] section of {TitleControllerAdminGuide}.
 
 This guide recommends that you configure {PlatformNameShort} and the underlying {RHEL} systems to collect logging and auditing centrally, rather than reviewing it on the local system. 
 {ControllerNameStart} must be configured to use external logging to compile log records from multiple components within the controller server. 
 The events occurring must be time-correlated to conduct accurate forensic analysis. 
-This means that the controller server must be configured with an NTP server that is also used by the logging aggregator service, as well as the targets of the controller. 
+This means that the {Controllername} server must be configured with an NTP server that is also used by the logging aggregator service, as well as the targets of {ControllerName}. 
 The correlation must meet certain industry tolerance requirements. 
 In other words, there might be a varying requirement that time stamps of different logged events must not differ by any amount greater than _x_ seconds. 
 This capability should be available in the external logging service.
 
-Another critical capability of logging is the ability to use cryptography to protect the integrity of log tools. Log data includes all information (for example, log records, log settings, and log reports) needed to successfully log information system activity. It is common for attackers to replace the log tools or inject code into the existing tools to hide or erase system activity from the logs. To address this risk, log tools must be cryptographically signed so that you can identify when the log tools have been modified, manipulated, or replaced. For example, one way to validate that the log tool(s) have not been modified, manipulated or replaced is to use a checksum hash against the tool file(s). This ensures the integrity of the tool(s) has not been compromised.
+Another critical capability of logging is the ability to use cryptography to protect the integrity of log tools. Log data includes all information (for example, log records, log settings, and log reports) needed to successfully log information system activity. 
+It is common for attackers to replace the log tools or inject code into the existing tools to hide or erase system activity from the logs. 
+To address this risk, log tools must be cryptographically signed so that you can identify when the log tools have been modified, manipulated, or replaced. 
+For example, one way to validate that the log tool(s) have not been modified, manipulated or replaced is to use a checksum hash against the tool file(s). 
+This ensures the integrity of the tool(s) has not been compromised.

downstream/modules/aap-hardening/con-rhel-host-planning.adoc

@@ -10,7 +10,7 @@
 The security of {PlatformNameShort} relies in part on the configuration of the underlying {RHEL} servers. 
 For this reason, the underlying {RHEL} hosts for each {PlatformNameShort} component must be installed and configured in accordance with the link:{BaseURL}/red_hat_enterprise_linux/8/html-single/security_hardening/index[Security hardening for {RHEL} 8] or link:{BaseURL}/red_hat_enterprise_linux/9/html-single/security_hardening/index[Security hardening for {RHEL} 9] (depending on which operating system will be used), as well as any security profile requirements (CIS, STIG, HIPAA, and so on) used by your organization.
 For new deployments, this document recommends {RHEL} 9 for all new deployments. 
-When using the container-based installation method, {RHEL} is required.
+When using the container-based installation method, {RHEL} 9 is required.
 
 //Note that applying certain security controls from the STIG or other security profiles may conflict with {PlatformNameShort} support requirements. 
 //Some examples are listed in the xref:con-controller-stig-considerations_{context}[{ControllerNameStart} STIG considerations] section, although this is not an exhaustive list. To maintain a supported configuration, be sure to discuss any such conflicts with your security auditors so the {PlatformNameShort} requirements are understood and approved.

downstream/modules/aap-hardening/con-user-authentication-planning.adoc

@@ -7,15 +7,14 @@
 
 [role="_abstract"]
 
-When planning for access to the {PlatformNameShort} user interface or API, be aware that user accounts can either be local or mapped to an external authentication source such as LDAP. This guide recommends that where possible, all primary user accounts should be mapped to an external authentication source. Using external account sources eliminates a source of error when working with permissions in this context and minimizes the amount of time devoted to maintaining a full set of users exclusively within {PlatformNameShort}. This includes accounts assigned to individual persons as well as for non-person entities such as service accounts used for external application integration. Reserve any local administrator accounts such as the default "admin" account for emergency access or "break glass" scenarios where the external authentication mechanism is not available.
-
-
-[NOTE]
-====
-The {EDAcontroller} does not currently support external authentication, only local accounts.
-====
-
-For user accounts on the {RHEL} servers that run the {PlatformNameShort} services, follow your organizational policies to determine if individual user accounts should be local or from an external authentication source. Only users who have a valid need to perform maintenance tasks on the {PlatformNameShort} components themselves should be granted access to the underlying {RHEL} servers, as the servers will have configuration files that contain sensitive information such as encryption keys and service passwords. Because these individuals must have privileged access to maintain {PlatformNameShort} services, minimizing the access to the underlying {RHEL} servers is critical. Do not grant sudo access to the root account or local {PlatformNameShort} service accounts (awx, pulp, postgres) to untrusted users.
+When planning for access to the {PlatformNameShort} user interface or API, be aware that user accounts can either be local or mapped to an external authentication source such as LDAP. 
+This guide recommends that where possible, all primary user accounts should be mapped to an external authentication source. 
+Using external account sources eliminates a source of error when working with permissions in this context and minimizes the amount of time devoted to maintaining a full set of users exclusively within {PlatformNameShort}. This includes accounts assigned to individual persons as well as for non-person entities such as service accounts used for external application integration. 
+Reserve any local administrator accounts such as the default "admin" account for emergency access or "break glass" scenarios where the external authentication mechanism is not available.
+
+For user accounts on the {RHEL} servers that run the {PlatformNameShort} services, follow your organizational policies to determine if individual user accounts should be local or from an external authentication source. 
+Only users who have a valid need to perform maintenance tasks on the {PlatformNameShort} components themselves should be granted access to the underlying {RHEL} servers, as the servers will have configuration files that contain sensitive information such as encryption keys and service passwords. 
+Because these individuals must have privileged access to maintain {PlatformNameShort} services, minimizing the access to the underlying {RHEL} servers is critical. Do not grant sudo access to the root account or local {PlatformNameShort} service accounts (awx, pulp, postgres) to untrusted users.
 
 [NOTE]
 ====

downstream/modules/aap-hardening/ref-dns-load-balancing.adoc

@@ -12,6 +12,10 @@ When using a load balancer with {PlatformNameShort} as described in the referenc
 For example, if the following hosts are defined in the {PlatformNameShort} installer inventory file:
 
 -----
+[automationgateway]
+gateway0.example.com
+gateway1.example.com
+
 [automationcontroller]
 controller0.example.com
 controller1.example.com
@@ -21,6 +25,11 @@ controller2.example.com
 hub0.example.com
 hub1.example.com
 hub2.example.com
+
+[automationedacontroller]
+edacontroller0.example.com
+edacontroller1.example.com
+edacontroller2.example.com
 -----
 
 Then the load balancer can use the FQDNs `controller.example.com` and `hub.example.com` for the user-facing name of these {PlatformNameShort} services.

downstream/modules/aap-hardening/ref-dns.adoc

@@ -5,4 +5,5 @@
 
 [role="_abstract"]
 
-When installing {PlatformNameShort}, the installer script checks that certain infrastructure servers are defined with a Fully Qualified Domain Name (FQDN) in the installer inventory. This guide recommends that all {PlatformNameShort} infrastructure nodes have a valid FQDN defined in DNS which resolves to a routable IP address, and that these FQDNs be used in the installer inventory file.
+When installing {PlatformNameShort}, the installer script checks that certain infrastructure servers are defined with a _Fully Qualified Domain Name_ (FQDN) in the installer inventory. 
+This guide recommends that all {PlatformNameShort} infrastructure nodes have a valid FQDN defined in DNS which resolves to a routable IP address, and that these FQDNs be used in the installer inventory file.

downstream/modules/aap-hardening/ref-security-variables-install-inventory.adoc

@@ -15,7 +15,7 @@ The following table lists a number of security-relevant variables and their reco
 [cols="25%,25%,25%,25%",options="header"]
 |===
 | *RPM Variable* | *Containerized Variable* | *Recommended Value* | *Details*
-| `postgres_use_ssl` | 'postgre_disable_tls` |true | Determines if the connection between Ansible Automation Platform and the PostgreSQL database should use SSL/TLS. 
+| `postgres_use_ssl` | `postgre_disable_tls` |true | Determines if the connection between Ansible Automation Platform and the PostgreSQL database should use SSL/TLS. 
 
 The default for this variable is false which means SSL/TLS is not used for PostgreSQL connections.