-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revision of hardening guide #2526
base: main
Are you sure you want to change the base?
Conversation
8e02d80
to
c460b17
Compare
Introduction and initial text Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
More changes Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
More edits, link with module in Controller-AG Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Modified logging section Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Added logging procedure Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Corrected symlink Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Added new chapter and modules Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Correction Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Correction Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Corrections Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Correction Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Removed TBDs and partially rewrote the architecture section Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Additional changes from Chris Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple initial notes for review, I will complete another review following further changes from out WG.
downstream/modules/aap-hardening/con-network-firewall-services-planning.adoc
Outdated
Show resolved
Hide resolved
downstream/modules/aap-hardening/ref-infrastructure-as-code.adoc
Outdated
Show resolved
Hide resolved
Corrections from review Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Corrections Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Removed section and added image Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
Removed xrefs Document how to secure and harden AAP https://issues.redhat.com/browse/AAP-32887
@@ -10,15 +10,29 @@ ifdef::context[:parent-context: {context}] | |||
|
|||
This document provides guidance for improving the security posture (referred to as “hardening” throughout this guide) of your {PlatformName} deployment on {RHEL}. | |||
|
|||
Other deployment targets, such as OpenShift, are not currently within the scope of this guide. {PlatformNameShort} managed services available through cloud service provider marketplaces are also not within the scope of this guide. | |||
The following are not currently withoin the scope of this guide: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo in this line
* Reduces error-prone manual effort. | ||
* Decreases time to deploy patches at scale. | ||
* Ensures consistency of patches across similar systems. Manual patching of similar systems can result in human error (forgetting one or more, patching using different versions) that impacts consistency. | ||
* Enables orchestration of complex patching scenarios where an update mightmay require taking a system snapshot before applying a patch, or might require additional configuration changes when the patch is applied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo in this line-- "mightmay"
|
||
* 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. | ||
* 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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider using the attribute for automation controller in this line {ControllerName}
|
||
|
||
* {ControllerNameStart} | ||
* Automation mesh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do have attributes for automation mesh:
:AutomationMesh: automation mesh
:AutomationMeshStart: Automation mesh
|
||
There are a few main concepts that you should become familiar with regarding {ControllerName}'s RBAC design–roles, resources, and users. Users can be members of a role, which gives them certain access to any resources associated with that role, or any resources associated with “descendant” roles. | ||
There are a few main concepts that you should become familiar with regarding {PlatformNameShort}'s RBAC design–roles, resources, and users. | ||
Users can be members of a role, which gives them certain access to any resources associated with that role, or any resources associated with “descendant” roles. | ||
|
||
A role is essentially a collection of capabilities. Users are granted access to these capabilities and the controller’s resources through the roles to which they are assigned or through roles inherited through the role hierarchy. | ||
|
||
Roles associate a group of capabilities with a group of users. All capabilities are derived from membership within a role. Users receive capabilities only through the roles to which they are assigned or through roles they inherit through the role hierarchy. All members of a role have all capabilities granted to that role. Within an organization, roles are relatively stable, while users and capabilities are both numerous and may change rapidly. Users can have many roles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This passage repeats some of the info and wording in the sentence above it. If this is deliberate, ignore this comment
There is a difference between the user interface (web interface) and access to the operating system that the {ControllerName} is running on. | ||
A system administrator or root user can access, edit, and disrupt any system application. | ||
with root access to the controller has the potential ability to decrypt those credentials, and so minimizing access to system administrative accounts is crucial for maintaining a secure system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Word missing before "with root access"?
= Keeping everything up to date | ||
|
||
For some RHEL servers, such as a lab or other non-production systems, you might want to install all available patches on a regular cadence. | ||
he following example playbook might be used in a job template that is scheduled to run weekly, and updates the system with all of the latest RPMs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"he" should probably be "The" in this line
The following example is set up for Splunk: | ||
+ | ||
image:configure-controller-system-logging-splunk-example.png[Splunk logging example] | ||
|
||
endif::controller-AG[] | ||
* *Enable External Logging*: Select this checkbox if you want to send logs to an external log aggregator. | ||
* *Enable/disable HTTPS certificate verification*: Certificate verification is enabled by default for the HTTPS log protocol. | ||
Select this checkbox if yoiu want the log handler to verify the HTTPS certificate sent by the external log aggregator before establishing a connection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo in "you"
Introduction and initial text
Document how to secure and harden AAP
https://issues.redhat.com/browse/AAP-32887