feat: More flexibility on the plugin language

[yana1205]

Issue description / feature objectives

Building on @jpower432 's suggestion in this thread it would be beneficial to explore ways to enhance flexibility in the plugin language without necessitating the creation of multiple compliance-to-policy core repositories. This could help minimize duplication and improve overall efficiency.

Caveats / Assumptions

No response

Completion Criteria

This issue is for discussion item. Discuss and find ways to enhance the flexibility.

Related links

slack: https://cloud-native.slack.com/archives/C06F3PEPNBW/p1717786627638569?thread_ts=1717786588.204509&cid=C06F3PEPNBW
issue: This issue can be a follow-up item of #22.

[jpower432]

Thanks for opening this issue @yana1205!

I would like to validate some assumptions I have and see if they match up with the current project goals/design. I think it may guide or provide guardrails around the discussion of approaches to ensure we are aligned. Please let me know if anything below is different from your perspective.

1. The purpose of supporting other languages like Go is to give more flexibility to PVP plugin developers
2. Keeping the core OSCAL supporting logic in Python would simplify maintenance because compliance-trestle is written in Python
3. Per the current design, this is meant to primarily be consumed as a CLI to simplify usage in CI/CD pipelines

Also a ROADMAP question that I think may be relevant - Would running the actual policy validation be out of scope for a PVP plugin?

[yana1205]

Hi @jpower432,

I was offline in a couple of days. Thank you for providing the points to clarify assumption! These are very good and helpful points to consider the level of flexibility. Yes, 1, 2, and 3 are exactly the assumption of C2P when using C2P as CLI in a task of CI/CD (or maybe DevSecOps) pipelines (GitHub Action, Tekton, Travis). Currently, we assume that this is a primary use case.

This is beyond the topic of plugin but if we consider that C2P is used as a library for flexible integration, for example natively embedded in a policy engine, a security tool, or own application, the scope of 1 and 3 could be broader, which could be "The purpose of supporting other languages like Go is to give more flexibility on the integration of C2P with your application". Cloud Native systems are typically characterized by loose coupling, and in this context, integration through a library might not be required as frequently.

Would running the actual policy validation be out of scope for a PVP plugin?

Yes, executing policy validation is responsible of Policy Engine (OCM Policy Framework, Kyverno, OPA Gatekeeper, Auditree, Ansible). However, there is no constraints on the implementation of the plugin as long as it meets the requirements defined by the interface. Actually, a developer can implement the logic of a policy validation inside the plugin.

[jpower432]

Thanks @yana1205. That clarifies a lot for me.

I'd like to understand the library use case better and how other systems could integrate. Integration flexibility makes sense to me.
Using a language-flexible way to define the plugin interface could be even more helpful in this context to allow for the integration of community-developed plugins without needing to duplicate them for each supported language.

Wanted to throw out some ideas/considerations that might be worth exploring to see what you think:

• Defined a standard API or interface via protobuf
• Use code generation tools to reduce boilerplate code for plugin developers
• Define how this is exchanged - gRPC over UDS might be an idea, but maybe more simple options like named pipes or files could be explored.

cc @gvauter

[yana1205]

I'd like to understand the library use case better and how other systems could integrate. Integration flexibility makes sense to me.

The library is intended for use cases beyond the GitOps pipeline. For instance, when a PVP directly sends the results to a compliance administration tool in OSCAL-ish, I think that it's more flexible if there is an option for the PVP to invoke C2P to convert the native format to OSCAL in their code.

Wanted to throw out some ideas/considerations that might be worth exploring to see what you think:

Thanks! File (File I/O or Standard I/O) looks the simplest way to me. In that case, a plugin is provided as an executable file and the core invokes it. gRPC looks more robust and enables the plugin to complex tasks.

To summarize in more detail, it would be as follows:

interface	pros	cons	reference software
gRPC, REST API	strong typing, error handling, complex communication, complex tasks	development effort (require protobuf, openapi)	Terraform
File, Standard I/O	straightforward	lack of strong typing, complex communication	Kustomize, CNI
Program module/class/function	straightforward, strong typing, error handling	language dependent	pytest, C2P

The current C2P is the last one. The plugin is delivered as Python modules so in both cases of RPC and File, the C2P core needs enhancement to handle an executable format. I am positive about that enhancement.

I haven't yet reached a conclusion on which is better RPC or File (or whatever other interface) but here is my thought:
File or standard I/O is enough for the current responsibility of plugin. However, gRPC is advantageous if the scope of plugin covers delivery of policies and collection of results like Terraform plugin.
Simply put, gRPC is more capable but requires more C2P development effort, whereas using files is less demanding but may not handle complex tasks as effectively. Let me take more time to consider... I would welcome any comments.

[jpower432]

@yana1205 You have brought forth some really great points. The table is really helpful. As you stated, this decision seems to be heavily dependent on project scope/vision. If policy delivery, policy execution, or results collection are in scope, combined with the various policy engine types that would be supported (e.g., declarative, imperative, short-lived processes, long-lived processes), gRPC may be a more scalable foundation, given that data exchange would become more complex. I hope this comment is helpful.

[jpower432]

Hi @yana1205. Now that #22 is in progress, I wanted to revisit this issue. With the recent approval of the oscal-sdk-go project, I'm wondering if it might be beneficial to incorporate the core plugin management logic described here into the Go version of C2P. This could potentially improve performance and leverage the maturity of the gRPC ecosystem in Go (if that approach is chosen). I'm curious to hear your thoughts.

[yana1205]

@jpower432 Yes, I agree with that writing in Go is a right way for gRPC, and also I agree with creating the core plugin management logic in Go and gRPC. If we're building a new framework with gRPC, it might be easier to just separate the existing code into its own directory like "v1", rather than trying to follow the existing structure. That way, we could start fresh with the new one. It does depend, though, on how different the new framework would be.

[jpower432]

@yana1205 Sounds good. I will open a new issue on the Go repository where we can discuss the framework so we can decide whether to create a v2 module.