Support remediation engines

[jpower432]

Objectives

Add support for plugin types that perform policy based actions beyond validation (e.g. policy-based remediation)

Rationale

Adding different types of generation-based plugins extends support to policy action that define a blueprint or take corrective steps when the system deviates from the desired state. This can be a valuable additional to the continuous compliance workflow supported by C2P.

Completion Criteria

• Decouple generation support from PVP results transformation
• Decouple plugin workflows from the PluginManager to allow for more complex plugin-based workflows.

[jpower432]

@marcusburghardt Adding a note here - Since the creation of remediation artifacts could be considered a type of policy action (e.g. enforcement, validation, remediation), we could consider using the existing generation plugin type and customizing the RuleSet/Policy input based on the requirement above. Thoughts?

[marcusburghardt]

@marcusburghardt Adding a note here - Since the creation of remediation artifacts could be considered a type of policy action (e.g. enforcement, validation, remediation), we could consider using the existing generation plugin type and customizing the RuleSet/Policy input based on the requirement above. Thoughts?

I agree with that @jpower432 . I believe the same source of information (assessment-plan) used to generate validation policies could be perfectly used to generate remediation policies. I also believe that using the same information to generate both validation and remedation policies would make the process simpler, with means easier to generate, test, audit, consume, and maintain.

One important aspect is that a validation policy, by nature, does not change the system. While the remediation policy is expected to change the system. In this context, all remediation policies should ensure idempotency, which is something pretty doable in many available technologies.

[jpower432]

@marcusburghardt I updated the description based on the above discussion.

[jpower432]

@yana1205 I think the updated description may align with what you were describing in this comment with regard to component reuse in complex operations.

The original goal in this issue was to expand the plugin API spec to define another technology-focused interface (a remediation engine). The updated goal focuses on capabilities-based (or grouped capability) interfaces that could result support reuse in different contexts.

Example of a Potential Workflow

graph LR;

A((OSCAL)) --Action--> B[Policy Generation]
B --> C((Policy as a Blueprint for Desired State))
C --Action--> D[Validation]
C --Action--> E[Enforcement]
C --Action--> F[Remediation]
D --> G((PVP Results))
G --Action--> H[Results Aggregation]
H --> A

Loading

I am wondering if you could share your thoughts on this. Do you think the results transformation relies heavily enough on the implementation details of policy generation that we should always enforce the implementation of both for a single plugin? Keeping in mind that if we break them down into two interfaces, one plugin is able to implement and register multiple interfaces implementations with go-plugin.