Open yana1205 opened 3 months ago
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.
compliance-trestle
is written in PythonAlso a ROADMAP question that I think may be relevant - Would running the actual policy validation be out of scope for a PVP plugin?
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.
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:
cc @gvauter
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.
@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.
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.