devel to main for release

docs/source/audit/audit-faq.rst

@@ -1,3 +1,14 @@
 Audit - FAQ
------------
-None currently
+===========
+
+Why does goss run manually fail?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+example.
+
+.. code-block:: bash
+
+   goss -g goss.yml -v
+
+Goss is designed to run from the scripts passing discovered variables into Goss for metadata. Without these values being set, Goss will fail. These metadata variables can bee seen towards the end of the goss.yml file. With the run_audit script showing how these variables are created and passed to Goss.
+

docs/source/remediate/rem-faq.rst

@@ -1,76 +1,22 @@
 Remediate - FAQ
 ===============
 
-Does this role work only with |benchmark_os_short|?
------------------------------------------------------
+jmespath fatal error
+^^^^^^^^^^^^^^^^^^^^
 
-No -- it works on multiple distributions!
+.. code-block:: bash
 
-The |benchmark_name| guidance is designed to ONLY apply to |benchmark_os|
-systems. If you are using this role in a regulated organization you should be aware
-that applying these settings to distributions other than those listed is unsupported
-and may run afoul of your organization or regulatory bodies guidelines during a compliance
-audit. Due diligence is **YOUR BURDEN** to understand your organization's requirements, laws,
-and regulations you must adhere to before applying for this role.
+   fatal: [ansible]: FAILED! => {"msg": "You need to install \"jmespath\" prior to running json_query filter"}
 
-See :ref:`system_applicability_ref_label` below for more details on applying this role to non-|benchmark_os|.
+This can occur during a playbook run on certain operating systems when patching takes place as part of the playbook due to the way python is implemented.
 
+* `You Need to install jmespath <https://serverfault.com/questions/1114638/ansible-you-need-to-install-jmespath-prior-to-running-json-query-filter-bu>`_ : A great article and explaination written by discord community member baassssiiee
 
-Why should this role be applied to a system?
---------------------------------------------
+Missing sudo password
+^^^^^^^^^^^^^^^^^^^^^
 
-There are three main reasons to apply this role to production Linux systems:
+Many of the CIS (section 5.x) roles remove the ability for sudoers to use the NOPASSWD option to enable elevated privileges.
 
-Improve security posture
-  The configurations from the |benchmark_name| add security and rigor around multiple
-  components of a Linux system, including user authentication, service
-  configurations, and package management. All of these configurations add up
-  to an environment that is more difficult for an attacker to penetrate and use
-  for lateral movement.
+The user (unless root) that is running the playbook on the target should have a password set and the playbook run accordingly to pass the become_password.
 
-Meet compliance requirements
-  Some deployers may be subject to industry compliance programs, such as
-  PCI-DSS, ISO 27001/27002, or NIST 800-53. Many of these programs require
-  hardening standards to be applied to systems.
-
-Deployment without disruption
-  Security is often at odds with usability. The role provides the greatest
-  security benefit without disrupting production systems. Deployers have the
-  option to opt out or opt in for most configurations depending on how their
-  environments are configured.
-
-.. _system_applicability_ref_label:
-
-Which systems are covered?
---------------------------------------------------------
-
-This role and the |benchmark_name| guidance it implements are fully applicable to servers
-(physical or virtual) and containers running the following Linux distributions:
-
-* |benchmark_os|
-
-
-
-The role is tested against each distribution to ensure that tasks run properly.
-It is idempotent, and an Audit is used to run a compliance scan after the role
-is applied to test compliance with the |benchmark_name| standard.
-
-Which systems are not covered?
-------------------------------
-
-This role will run properly against a container (docker or other), however
-this is not recommended and is only useful during the development and
-testing of this role (ie most CI systems provide containers and not full VMs),
-so this role must be able to run on and test against containers.
-
-**Again for those in the back** ...applying this role against a container
-to secure it is generally a **BAD** idea. You should be applying this
-role to your container's hosts and then using other hardening guidance that is
-specific to the container technology you are using (docker, lxc, lxd, etc).
-
-.. |benchmark_name| replace:: CIS
-.. |benchmark_os| replace:: RedHat Enterprise Linux 9
-.. |benchmark_os_short| replace:: RHEL9
-.. |benchmark_version| replace:: v1.0.0
-.. |benchmark_release_date| replace:: 11-30-2022
-.. |lockdown_url| replace:: https://github.com/ansible-lockdown/|benchmark_os_short|-|benchmark_name|
+All repositories should now run a pre-req check to ensure that the user does have a password set and will fail if this is not setup.