Remediating compliance violations
This topic provides an overview of the Remediate span action and describes how to run this action to remediate compliance violations.
A job with the Remediate action runs the corrective actions defined in the violated rules. For each device in the selected network span, the job runs the corrective action for each trail that is currently in violation of a selected rule. Note that only active violations are corrected, as maintained during configuration snapshot change processing or by running a Refresh Device Status action.
A Remediate action can run any type of corrective action as compared to Deploy to Active and Deploy to Stored actions. When you choose a remediating configuration, these actions can run only the Deploy to Active or Deploy to Stored corrective actions. A Remediate action can also run Deploy OS Image and custom actions.
A Remediate action expands into one or more sub-actions, each one of which executes one or more corrective actions. This process forms a hierarchy of actions that can be observed when previewing the configurations, when viewing the job details, and in the Job Summary report. The Remediate action itself carries no per-device results; the sub-actions get the per-device results.
During upgrade, the existing rules that are associated with the running trail are automatically given a Deploy to Active corrective action, which pushes a compliant configuration by using incremental merge when supported. Rules that are associated with the startup configuration are automatically given a Deploy to Startup corrective action, which pushes a compliant configuration. However, any rule which has OS Image Name as the domain does not get any corrective actions.
You can control access to the Remediate span action through the Run Associated Remediate Actions network right. If you have this right, you can execute any type of corrective action. For example, if you do not have the right to perform the Deploy OS Image action but you do have the right to run the Remediate action, you are allowed to remediate rules whose corrective action is Deploy OS Image. You still cannot run the Deploy OS Image action directly, but only from within a Remediate action. Also, network span action rights do not affect your ability to access rule sets or rules; that is, you can create and edit rules with any type of corrective action, no matter what your network span action rights are. During upgrade, only the Administrator role receives the right to run the Remediate span action. You must edit the required roles to grant this right as appropriate to your site.
During upgrade, the system parameter Enable Job Approval For Actions does not include the Remediate action by default. You must edit the system parameter based on your job approval plan, and decide if the Remediate action should be selected.
The following video (4:03) explains how to run a Remediate action.
To run the Remediate action
- On the Add Job page, select Add Action > Span Actions > Remediate.
Enter information in the following fields:
(Optional) Specify an annotation that will be assigned to the configurations created by the action
Select a realm, group, multiple devices, or a single device for the Remediate action. When the network span is Realm or Group, you can use Filter Devices to select which devices to include in the action.
When the action is triggered in an event-based policy, additional options include: Same as Triggering Realm, Same as Triggering Group, and Same as Triggering Device.
- In the Remediate With field, select which rules that are currently in violation are to be remediated or corrected:
All Assigned: Remediate all or a subset of the currently assigned rule sets.
Click Filter Rules to set the rule filter criteria. For example, you might want to enforce assigned rules based on violation severity.
- Selected Rule Set(s) and/or Rule(s): Remediate any number of selected rule sets, rules, or both.
Select any of the following options, as relevant:
Collapse Duplicate Sub-Actions
- When this option is selected, the corrective actions are collapsed into as few sub-actions as possible. This process minimizes the number of configuration changes generated by executing this action.
- When this option is not selected, each corrective action is its own individual sub-action, with its associated trailing snapshot, which could generate a configuration change per sub-action.
Normally, you should select this option, unless you encounter any error or difficulty in the execution of collapsed sub-action.
Use Auxiliary Interface
- When this option is selected and the selected network span is a device, the auxiliary interface is used for connecting to the device.
- When this option not selected or when the span is not a device, the primary interface is used for connecting to the device.
Ignore Any Rule Conflicts
When remediating multiple rules, ignore any conflicts between corrections in different rules. By default, such conflicts are not ignored, and they cause the action to fail to generate the compliant configuration, since conflicts usually lead to incorrect syntax or unexpected changes. Ignore conflicts only when you have reviewed the compliant configuration and verified that it is correct in spite of conflicts.
Note: Only conflicts within a single sub-action can be detected for sub-actions that generate a compliant configuration. The system cannot detect conflicts across different sub-actions. For example, the system cannot detect that two sub-actions each pushing a template contain conflicting commands in the templates, or that two image deployments cancel each other out. Use the Preview option to review the details of the sub-actions when remediating many violations at once.
- Click OK to add the action to the job.
You can preview the compliant configurations, incremental merge scripts, and resolved templates by clickingon the Add Job page, as shown in the following figure. To assess the change against the current configurations, click . BMC Network Automation displays a Compliance Summary Report for analysis.