diff --git a/modules/compliance-apply-remediation-for-customized-mcp.adoc b/modules/compliance-apply-remediation-for-customized-mcp.adoc index 307740caafa1..a42f50f87836 100644 --- a/modules/compliance-apply-remediation-for-customized-mcp.adoc +++ b/modules/compliance-apply-remediation-for-customized-mcp.adoc @@ -2,6 +2,7 @@ [id="compliance-operator-apply-remediation-for-customized-mcp"] = Applying remediation when using customized machine config pools +[role="_abstract"] When you create a custom `MachineConfigPool`, add a label to the `MachineConfigPool` so that `machineConfigPoolSelector` present in the `KubeletConfig` can match the label with `MachineConfigPool`. [IMPORTANT] @@ -18,7 +19,7 @@ Do not set `protectKernelDefaults: false` in the `KubeletConfig` file, because t $ oc get nodes -n openshift-compliance ---- + -.Example output +The command output displays the nodes in the cluster: + [source,terminal] ---- @@ -30,7 +31,7 @@ ip-10-0-171-170.us-east-2.compute.internal Ready master 5h21m v1.35.4 ip-10-0-197-35.us-east-2.compute.internal Ready master 5h22m v1.35.4 ---- -. Add a label to nodes. +. Add a label to the target nodes: + [source,terminal] ---- @@ -39,14 +40,14 @@ label node ip-10-0-166-81.us-east-2.compute.internal \ node-role.kubernetes.io/= ---- + -.Example output +The console verifies that the node has been successfully labeled: + [source,terminal] ---- node/ip-10-0-166-81.us-east-2.compute.internal labeled ---- -. Create custom `MachineConfigPool` CR. +. Create the custom `MachineConfigPool` custom resource (CR). Ensure that the `labels` field defines the label name you intend to add for the machine config pool: + [source,yaml] ---- @@ -55,7 +56,7 @@ kind: MachineConfigPool metadata: name: labels: - pools.operator.machineconfiguration.openshift.io/: '' <1> + pools.operator.machineconfiguration.openshift.io/: '' spec: machineConfigSelector: matchExpressions: @@ -64,9 +65,8 @@ spec: matchLabels: node-role.kubernetes.io/: "" ---- -<1> The `labels` field defines label name to add for Machine config pool(MCP). -. Verify MCP created successfully. +. Verify that the machine config pool was created successfully: + [source,terminal] ---- diff --git a/modules/compliance-applying.adoc b/modules/compliance-applying.adoc index 73e3482cdc25..499159f0d2d2 100644 --- a/modules/compliance-applying.adoc +++ b/modules/compliance-applying.adoc @@ -6,27 +6,35 @@ [id="compliance-applying_{context}"] = Applying a remediation +[role="_abstract"] The boolean attribute `spec.apply` controls whether the remediation should be applied by the Compliance Operator. You can apply the remediation by setting the attribute to `true`: +.Procedure + +. Apply the remediation by setting the `spec.apply` attribute to `true`: ++ [source,terminal] ---- $ oc -n openshift-compliance \ patch complianceremediations/-sysctl-net-ipv4-conf-all-accept-redirects \ --patch '{"spec":{"apply":true}}' --type=merge ---- ++ +After the Compliance Operator processes the applied remediation, the `status.ApplicationState` attribute changes to *Applied* (or to *Error* if the configuration is incorrect). ++ +When a machine config remediation is applied, it is rendered along with all other applied remediations into a single composite `MachineConfig` object named `75-$scan-name-$suite-name`. This object is subsequently processed by the Machine Config Operator and applied to all pool nodes by the machine control daemon instance running on each node. ++ +[NOTE] +==== +When the Machine Config Operator applies a new `MachineConfig` object to a pool, all nodes belonging to that pool are rebooted. To prevent immediate reboots when applying multiple remediations, you can pause the machine config pool by setting the `.spec.paused` attribute of the corresponding `MachineConfigPool` object to `true`. +==== -After the Compliance Operator processes the applied remediation, the `status.ApplicationState` attribute would change to *Applied* or to *Error* if incorrect. When a machine config remediation is applied, that remediation along with all other applied remediations are rendered into a `MachineConfig` object named `75-$scan-name-$suite-name`. That `MachineConfig` object is subsequently rendered by the Machine Config Operator and finally applied to all the nodes in a machine config pool by an instance of the machine control daemon running on each node. - -Note that when the Machine Config Operator applies a new `MachineConfig` object to nodes in a pool, all the nodes belonging to the pool are rebooted. This might be inconvenient when applying multiple remediations, each of which re-renders the composite `75-$scan-name-$suite-name` `MachineConfig` object. To prevent applying the remediation immediately, you can pause the machine config pool by setting the `.spec.paused` attribute of a `MachineConfigPool` object to `true`. - -The Compliance Operator can apply remediations automatically. Set `autoApplyRemediations: true` in the `ScanSetting` top-level object. - +. Optional: To configure the Compliance Operator to apply remediations automatically without manual intervention, set `autoApplyRemediations: true` in your top-level `ScanSetting` object. ++ [WARNING] ==== -Applying remediations automatically should only be done with careful consideration. +Applying remediations automatically should only be done with careful consideration and prior testing. ==== - ++ [IMPORTANT] -==== The Compliance Operator does not automatically resolve dependency issues that can occur between remediations. Users should perform a rescan after remediations are applied to ensure accurate results. -==== \ No newline at end of file diff --git a/modules/compliance-custom-node-pools.adoc b/modules/compliance-custom-node-pools.adoc index 7247552ebee1..eb46eeadcc1e 100644 --- a/modules/compliance-custom-node-pools.adoc +++ b/modules/compliance-custom-node-pools.adoc @@ -6,6 +6,7 @@ [id="compliance-custom-node-pools_{context}"] = Scanning custom node pools +[role="_abstract"] The Compliance Operator does not maintain a copy of each node pool configuration. The Compliance Operator aggregates consistent configuration options for all nodes within a single node pool into one copy of the configuration file. The Compliance Operator then uses the configuration file for a particular node pool to evaluate rules against nodes within that pool. .Procedure diff --git a/modules/compliance-evaluate-kubeletconfig-rules.adoc b/modules/compliance-evaluate-kubeletconfig-rules.adoc index 4fa6d28c035f..03c595c3f35d 100644 --- a/modules/compliance-evaluate-kubeletconfig-rules.adoc +++ b/modules/compliance-evaluate-kubeletconfig-rules.adoc @@ -6,6 +6,7 @@ [id="compliance-evaluate-kubeletconfig-rules_{context}"] = Evaluating KubeletConfig rules against default configuration values +[role="_abstract"] {product-title} infrastructure might contain incomplete configuration files at run time, and nodes assume default configuration values for missing configuration options. Some configuration options can be passed as command-line arguments. As a result, the Compliance Operator cannot verify if the configuration file on the node is complete because it might be missing options used in the rule checks. To prevent false negative results where the default configuration value passes a check, the Compliance Operator uses the Node/Proxy API to fetch the configuration for each node in a node pool, then all configuration options that are consistent across nodes in the node pool are stored in a file that represents the configuration for all nodes within that node pool. This increases the accuracy of the scan results. diff --git a/modules/compliance-filtering-results.adoc b/modules/compliance-filtering-results.adoc index ca7da5677d86..307229b4b19c 100644 --- a/modules/compliance-filtering-results.adoc +++ b/modules/compliance-filtering-results.adoc @@ -6,6 +6,7 @@ [id="filtering-compliance-check-results_{context}"] = Filters for compliance check results +[role="_abstract"] By default, the `ComplianceCheckResult` objects are labeled with several useful labels that allow you to query the checks and decide on the next steps after the results are generated. List checks that belong to a specific suite: diff --git a/modules/compliance-inconsistent.adoc b/modules/compliance-inconsistent.adoc index 66fd67843bda..0fffd23f76c0 100644 --- a/modules/compliance-inconsistent.adoc +++ b/modules/compliance-inconsistent.adoc @@ -6,19 +6,25 @@ [id="compliance-inconsistent_{context}"] = Inconsistent ComplianceScan +[role="_abstract"] The `ScanSetting` object lists the node roles that the compliance scans generated from the `ScanSetting` or `ScanSettingBinding` objects would scan. Each node role usually maps to a machine config pool. -[IMPORTANT] -==== -It is expected that all machines in a machine config pool are identical and all scan results from the nodes in a pool should be identical. -==== +.Procedure +. Review your scan results and identify nodes that differ from the most common state. ++ +The `ScanSetting` object lists the node roles that the compliance scans generated from the `ScanSetting` or `ScanSettingBinding` objects would scan. Each node role usually maps to a machine config pool. ++ +IMPORTANT: It is expected that all machines in a machine config pool are identical and all scan results from the nodes in a pool should be identical. ++ If some of the results are different from others, the Compliance Operator flags a `ComplianceCheckResult` object where some of the nodes will report as `INCONSISTENT`. All `ComplianceCheckResult` objects are also labeled with `compliance.openshift.io/inconsistent-check`. ++ +Because the number of machines in a pool might be quite large, the Compliance Operator attempts to find the most common state and list the nodes that differ from the common state. The most common state is stored in the `compliance.openshift.io/most-common-status` annotation and the annotation `compliance.openshift.io/inconsistent-source` contains pairs of `hostname:status` of check statuses that differ from the most common status. If no common state can be found, all the `hostname:status` pairs are listed in the `compliance.openshift.io/inconsistent-source` annotation. ++ +If possible, a remediation is still created so that the cluster can converge to a compliant status. However, this might not always be possible and correcting the difference between nodes must be done manually. -Because the number of machines in a pool might be quite large, the Compliance Operator attempts to find the most common state and list the nodes that differ from the common state. The most common state is stored in the `compliance.openshift.io/most-common-status` annotation and the annotation `compliance.openshift.io/inconsistent-source` contains pairs of `hostname:status` of check statuses that differ from the most common status. If no common state can be found, all the `hostname:status` pairs are listed in the `compliance.openshift.io/inconsistent-source annotation`. - -If possible, a remediation is still created so that the cluster can converge to a compliant status. However, this might not always be possible and correcting the difference between nodes must be done manually. The compliance scan must be re-run to get a consistent result by annotating the scan with the `compliance.openshift.io/rescan=` option: - +. Force the compliance scan to re-run and obtain a consistent result by annotating the scan with the `compliance.openshift.io/rescan=` option: ++ [source,terminal] ---- $ oc -n openshift-compliance \ diff --git a/modules/compliance-kubeletconfig-sub-pool-remediation.adoc b/modules/compliance-kubeletconfig-sub-pool-remediation.adoc index c9243df9fcc1..9c615ebc1759 100644 --- a/modules/compliance-kubeletconfig-sub-pool-remediation.adoc +++ b/modules/compliance-kubeletconfig-sub-pool-remediation.adoc @@ -6,6 +6,7 @@ [id="compliance-kubeletconfig-sub-pool-remediation_{context}"] = Remediating `KubeletConfig` sub pools +[role="_abstract"] `KubeletConfig` remediation labels can be applied to `MachineConfigPool` sub-pools. .Procedure diff --git a/modules/compliance-manual.adoc b/modules/compliance-manual.adoc index 873db7e790df..a1fb1a0ea830 100644 --- a/modules/compliance-manual.adoc +++ b/modules/compliance-manual.adoc @@ -6,6 +6,7 @@ [id="compliance-manual_{context}"] = Remediating a platform check manually +[role="_abstract"] Checks for Platform scans typically have to be remediated manually by the administrator for two reasons: * It is not always possible to automatically determine the value that must be set. One of the checks requires that a list of allowed registries is provided, but the scanner has no way of knowing which registries the organization wants to allow. diff --git a/modules/compliance-removing-kubeletconfig.adoc b/modules/compliance-removing-kubeletconfig.adoc index aabc0ff8d4dd..3acb3531e501 100644 --- a/modules/compliance-removing-kubeletconfig.adoc +++ b/modules/compliance-removing-kubeletconfig.adoc @@ -6,6 +6,7 @@ [id="compliance-removing-kubeletconfig_{context}"] = Removing a KubeletConfig remediation +[role="_abstract"] `KubeletConfig` remediations are included in node-level profiles. In order to remove a KubeletConfig remediation, you must manually remove it from the `KubeletConfig` objects. This example demonstrates how to remove the compliance check for the `one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available` remediation. .Procedure @@ -17,7 +18,6 @@ $ oc -n openshift-compliance get remediation \ one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml ---- + -.Example output [source,yaml] ---- apiVersion: compliance.openshift.io/v1alpha1 @@ -28,7 +28,7 @@ metadata: creationTimestamp: "2022-01-05T19:52:27Z" generation: 1 labels: - compliance.openshift.io/scan-name: one-rule-tp-node-master <1> + compliance.openshift.io/scan-name: one-rule-tp-node-master compliance.openshift.io/suite: one-rule-ssb-node name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available namespace: openshift-compliance @@ -50,23 +50,16 @@ spec: spec: kubeletConfig: evictionHard: - imagefs.available: 10% <2> + imagefs.available: 10% outdated: {} type: Configuration status: applicationState: Applied ---- -<1> The scan name of the remediation. -<2> The remediation that was added to the `KubeletConfig` objects. -+ -[NOTE] -==== ++ [NOTE] If the remediation invokes an `evictionHard` kubelet configuration, you must specify all of the `evictionHard` parameters: `memory.available`, `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, and `imagefs.inodesFree`. If you do not specify all parameters, only the specified parameters are applied and the remediation will not function properly. -==== - -. Remove the remediation: -.. Set `apply` to false for the remediation object: +. Set the `apply` attribute to `false` for the remediation object to stop applying it: + [source,terminal] ---- @@ -74,8 +67,8 @@ $ oc -n openshift-compliance patch \ complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available \ -p '{"spec":{"apply":false}}' --type=merge ---- -+ -.. Using the `scan-name`, find the `KubeletConfig` object that the remediation was applied to: + +. Using the `scan-name` value obtained previously, find the `KubeletConfig` object that the remediation was applied to: + [source,terminal] ---- @@ -83,26 +76,19 @@ $ oc -n openshift-compliance get kubeletconfig \ --selector compliance.openshift.io/scan-name=one-rule-tp-node-master ---- + -.Example output [source,terminal] ---- NAME AGE compliance-operator-kubelet-master 2m34s ---- -.. Manually remove the remediation, `imagefs.available: 10%`, from the `KubeletConfig` object: + +. Manually remove the configuration line `imagefs.available: 10%` from the identified `KubeletConfig` object: + [source,terminal] ---- $ oc edit -n openshift-compliance KubeletConfig compliance-operator-kubelet-master ---- + -[IMPORTANT] -==== -All affected nodes with the remediation will be rebooted. -==== - -[NOTE] -==== -You must also exclude the rule from any scheduled scans in your tailored profiles that auto-applies the remediation, otherwise, the remediation will be re-applied during the next scheduled scan. -==== - +**Important:** All affected nodes with the remediation will be rebooted. ++ +**Note:** You must also exclude the rule from any scheduled scans in your tailored profiles that auto-applies the remediation. Otherwise, the remediation will be re-applied during the next scheduled scan. diff --git a/modules/compliance-results.adoc b/modules/compliance-results.adoc index a2a73ad9b2b2..640c049d36ab 100644 --- a/modules/compliance-results.adoc +++ b/modules/compliance-results.adoc @@ -6,10 +6,11 @@ [id="compliance-results_{context}"] = Obtaining Compliance Operator raw results from a persistent volume -.Procedure - +[role="_abstract"] The Compliance Operator generates and stores the raw results in a persistent volume. These results are in Asset Reporting Format (ARF). +.Procedure + . Explore the `ComplianceSuite` object: + [source,terminal] @@ -18,7 +19,6 @@ $ oc get compliancesuites nist-moderate-modified \ -o json -n openshift-compliance | jq '.status.scanStatuses[].resultsStorage' ---- + -.Example output [source,json] ---- { @@ -44,11 +44,10 @@ This shows the persistent volume claims where the raw results are accessible. $ oc get pvc -n openshift-compliance rhcos4-moderate-worker ---- + -.Example output [source,terminal] ---- -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE -rhcos4-moderate-worker Bound pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a 1Gi RWO gp2 92m +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE +rhcos4-moderate-worker Bound pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a 1Gi RWO gp2 92m ---- . Fetch the raw results by spawning a pod that mounts the volume and copying the results: @@ -58,7 +57,6 @@ rhcos4-moderate-worker Bound pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a 1Gi $ oc create -n openshift-compliance -f pod.yaml ---- + -.Example pod.yaml [source,yaml] ---- apiVersion: "v1" @@ -93,11 +91,6 @@ spec: ---- $ oc cp pv-extract:/workers-scan-results -n openshift-compliance . ---- -+ -[IMPORTANT] -==== -Spawning a pod that mounts the persistent volume will keep the claim as `Bound`. If the volume's storage class in use has permissions set to `ReadWriteOnce`, the volume is only mountable by one pod at a time. You must delete the pod upon completion, or it will not be possible for the Operator to schedule a pod and continue storing results in this location. -==== . After the extraction is complete, the pod can be deleted: + @@ -105,3 +98,8 @@ Spawning a pod that mounts the persistent volume will keep the claim as `Bound`. ---- $ oc delete pod pv-extract -n openshift-compliance ---- ++ +[IMPORTANT] +==== +Spawning a pod that mounts the persistent volume will keep the claim as `Bound`. If the volume's storage class in use has permissions set to `ReadWriteOnce`, the volume is only mountable by one pod at a time. You must delete the pod upon completion, or it will not be possible for the Operator to schedule a pod and continue storing results in this location. +==== diff --git a/modules/compliance-review.adoc b/modules/compliance-review.adoc index 3e14a2cae92c..55a4947d8df8 100644 --- a/modules/compliance-review.adoc +++ b/modules/compliance-review.adoc @@ -2,10 +2,11 @@ // // * security/compliance_operator/co-scans/compliance-operator-remediation.adoc -:_mod-docs-content-type: PROCEDURE +:_mod-docs-content-type: CONCEPT [id="compliance-review_{context}"] = Reviewing a remediation +[role="_abstract"] Review both the `ComplianceRemediation` object and the `ComplianceCheckResult` object that owns the remediation. The `ComplianceCheckResult` object contains human-readable descriptions of what the check does and the hardening trying to prevent, as well as other `metadata` like the severity and the associated security controls. The `ComplianceRemediation` object represents a way to fix the problem described in the `ComplianceCheckResult`. After first scan, check for remediations with the state `MissingDependencies`. Below is an example of a check and a remediation called `sysctl-net-ipv4-conf-all-accept-redirects`. This example is redacted to only show `spec` and `status` and omits `metadata`: @@ -35,7 +36,7 @@ status: The remediation payload is stored in the `spec.current` attribute. The payload can be any Kubernetes object, but because this remediation was produced by a node scan, the remediation payload in the above example is a `MachineConfig` object. For Platform scans, the remediation payload is often a different kind of an object (for example, a `ConfigMap` or `Secret` object), but typically applying that remediation is up to the administrator, because otherwise the Compliance Operator would have required a very broad set of permissions to manipulate any generic Kubernetes object. An example of remediating a Platform check is provided later in the text. -To see exactly what the remediation does when applied, the `MachineConfig` object contents use the Ignition objects for the configuration. See the link:https://coreos.github.io/ignition/specs/[Ignition specification] for further information about the format. In our example, `the spec.config.storage.files[0].path` attribute specifies the file that is being create by this remediation (`/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf`) and the `spec.config.storage.files[0].contents.source` attribute specifies the contents of that file. +To see exactly what the remediation does when applied, the `MachineConfig` object contents use the Ignition objects for the configuration. See the Ignition specification documentation in the Additional resources section for further information about the format. In our example, `the spec.config.storage.files[0].path` attribute specifies the file that is being create by this remediation (`/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf`) and the `spec.config.storage.files[0].contents.source` attribute specifies the contents of that file. [NOTE] ==== @@ -58,4 +59,9 @@ net.ipv4.conf.all.accept_redirects=0 [IMPORTANT] ==== The Compliance Operator does not automatically resolve dependency issues that can occur between remediations. Users should perform a rescan after remediations are applied to ensure accurate results. -==== \ No newline at end of file +==== + +[role="_additional_resources"] +== Additional resources + +* link:https://coreos.github.io/ignition/specs/[Ignition specification] diff --git a/modules/compliance-unapplying.adoc b/modules/compliance-unapplying.adoc index e24481a59610..504ed89680e4 100644 --- a/modules/compliance-unapplying.adoc +++ b/modules/compliance-unapplying.adoc @@ -6,6 +6,7 @@ [id="compliance-unapplying_{context}"] = Unapplying a remediation +[role="_abstract"] It might be required to unapply a remediation that was previously applied. .Procedure @@ -21,11 +22,7 @@ patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-acc . The remediation status will change to `NotApplied` and the composite `MachineConfig` object would be re-rendered to not include the remediation. + [IMPORTANT] -==== All affected nodes with the remediation will be rebooted. -==== - ++ [IMPORTANT] -==== The Compliance Operator does not automatically resolve dependency issues that can occur between remediations. Users should perform a rescan after remediations are applied to ensure accurate results. -==== \ No newline at end of file diff --git a/modules/compliance-updating.adoc b/modules/compliance-updating.adoc index daa2f934b1ae..c9e016a35292 100644 --- a/modules/compliance-updating.adoc +++ b/modules/compliance-updating.adoc @@ -6,6 +6,7 @@ [id="compliance-updating_{context}"] = Updating remediations +[role="_abstract"] When a new version of compliance content is used, it might deliver a new and different version of a remediation than the previous version. The Compliance Operator will keep the old version of the remediation applied. The {product-title} administrator is also notified of the new version to review and apply. A ComplianceRemediation object that had been applied earlier, but was updated changes its status to *Outdated*. The outdated objects are labeled so that they can be searched for easily. The previously applied remediation contents would then be stored in the `spec.outdated` attribute of a `ComplianceRemediation` object and the new updated contents would be stored in the `spec.current` attribute. After updating the content to a newer version, the administrator then needs to review the remediation. As long as the `spec.outdated` attribute exists, it would be used to render the resulting `MachineConfig` object. After the `spec.outdated` attribute is removed, the Compliance Operator re-renders the resulting `MachineConfig` object, which causes the Operator to push the configuration to the nodes. @@ -20,7 +21,8 @@ $ oc -n openshift-compliance get complianceremediations \ -l complianceoperator.openshift.io/outdated-remediation= ---- + -.Example output +The command output lists the configurations flagged with an outdated status: ++ [source,terminal] ---- NAME STATE @@ -37,22 +39,23 @@ $ oc -n openshift-compliance patch complianceremediations workers-scan-no-empty- --type json -p '[{"op":"remove", "path":/spec/outdated}]' ---- -. The remediation state will switch from `Outdated` to `Applied`: +. Verify that the remediation state has switched from `Outdated` to `Applied`: + [source,terminal] ---- $ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords ---- + -.Example output +The status display confirms the state change: ++ [source,terminal] ---- NAME STATE workers-scan-no-empty-passwords Applied ---- -. The nodes will apply the newer remediation version and reboot. - +. Monitor the process as the cluster nodes apply the newer remediation version and automatically reboot. ++ [IMPORTANT] ==== The Compliance Operator does not automatically resolve dependency issues that can occur between remediations. Users should perform a rescan after remediations are applied to ensure accurate results. diff --git a/security/compliance_operator/co-scans/compliance-operator-raw-results.adoc b/security/compliance_operator/co-scans/compliance-operator-raw-results.adoc index e15ca5e95383..d2f32416709d 100644 --- a/security/compliance_operator/co-scans/compliance-operator-raw-results.adoc +++ b/security/compliance_operator/co-scans/compliance-operator-raw-results.adoc @@ -4,6 +4,7 @@ include::_attributes/common-attributes.adoc[] :context: compliance-raw-results +[role="_abstract"] When proving compliance for your {product-title} cluster, you might need to provide the scan results for auditing purposes. include::modules/compliance-results.adoc[leveloffset=+1] diff --git a/security/compliance_operator/co-scans/compliance-operator-remediation.adoc b/security/compliance_operator/co-scans/compliance-operator-remediation.adoc index edd4707a3a35..ce80f1d5b317 100644 --- a/security/compliance_operator/co-scans/compliance-operator-remediation.adoc +++ b/security/compliance_operator/co-scans/compliance-operator-remediation.adoc @@ -6,11 +6,12 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] Each `ComplianceCheckResult` represents a result of one compliance rule check. If the rule can be remediated automatically, a `ComplianceRemediation` object with the same name, owned by the `ComplianceCheckResult` is created. Unless requested, the remediations are not applied automatically, which gives an {product-title} administrator the opportunity to review what the remediation does and only apply a remediation once it has been verified. [IMPORTANT] ==== -Full remediation for Federal Information Processing Standards (FIPS) compliance requires enabling FIPS mode for the cluster. To enable FIPS mode, you must run the installation program from a {op-system-base-full} computer configured to operate in FIPS mode. For more information about configuring FIPS mode on RHEL, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/assembly_installing-the-system-in-fips-mode_security-hardening[Installing the system in FIPS mode]. +Full remediation for Federal Information Processing Standards (FIPS) compliance requires enabling FIPS mode for the cluster. To enable FIPS mode, you must run the installation program from a {op-system-base-full} computer configured to operate in FIPS mode. For more information about configuring FIPS mode on RHEL, see the Installing the system in FIPS mode documentation in the Additional resources section. FIPS mode is supported on the following architectures: @@ -43,7 +44,8 @@ include::modules/compliance-removing-kubeletconfig.adoc[leveloffset=+1] include::modules/compliance-inconsistent.adoc[leveloffset=+1] -[role="_additional-resources"] +[role="_additional_resources"] == Additional resources +* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/assembly_installing-the-system-in-fips-mode_security-hardening[Installing the system in FIPS mode] * xref:../../../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-managing-about_nodes-nodes-managing[Modifying nodes]