From a8dcf6304cb2b4b751a00c36bb719258f915a116 Mon Sep 17 00:00:00 2001 From: Patrick Sy Date: Thu, 10 Oct 2024 18:35:31 +0200 Subject: [PATCH] feat(cnoe-verification): added description of the findings researching the validation and verification capabilities in the CNOE framework Refs: #IPCEICIS-467 --- content/en/docs/solution/tools/CNOE/_index.md | 3 + .../docs/solution/tools/CNOE/verification.md | 68 +++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 content/en/docs/solution/tools/CNOE/_index.md create mode 100644 content/en/docs/solution/tools/CNOE/verification.md diff --git a/content/en/docs/solution/tools/CNOE/_index.md b/content/en/docs/solution/tools/CNOE/_index.md new file mode 100644 index 0000000..0011792 --- /dev/null +++ b/content/en/docs/solution/tools/CNOE/_index.md @@ -0,0 +1,3 @@ +--- +title: CNOE +--- diff --git a/content/en/docs/solution/tools/CNOE/verification.md b/content/en/docs/solution/tools/CNOE/verification.md new file mode 100644 index 0000000..a39774c --- /dev/null +++ b/content/en/docs/solution/tools/CNOE/verification.md @@ -0,0 +1,68 @@ +--- +title: Validation and Verification +weigth: 100 +--- + +## Definition + +The CNOE docs do somewhat interchange validation and verification but for the +most part they adhere to the general definition: + +> Validation is used when you check your approach before actually executing an +> action. + +Examples: + +- Form validation before processing the data +- Compiler checking syntax +- Rust's borrow checker + +> Verification describes testing if your 'thing' complies with your spec + +Examples: + +- Unit tests +- Testing availability (ping, curl health check) +- Checking a ZKP of some computation + +--- + +## In CNOE + +It seems that both validation and verification within the CNOE framework are +not actually handled by some explicit component but should be addressed +throughout the system and workflows. + +As stated in the [docs](https://cnoe.io/docs/intro/capabilities/validation), +validation takes place in all parts of the stack by enforcing strict API usage +and policies (signing, mitigations, security scans etc, see usage of kyverno +for example), and using code generation (proven code), linting, formatting, +LSP. Consequently, validation of source code, templates, etc is more a best +practice rather than a hard fact or feature and it is up to the user +to incorporate them into their workflows and pipelines. This is probably +due to the complexity of the entire stack and the individual properties of +each component and applications. + +Verification of artifacts and deployments actually exists in a somewhat similar +state. The current CNOE reference-implementation does not provide sufficient +verification tooling. + +However, as stated in the [docs](https://cnoe.io/docs/reference-implementation/integrations/verification) +within the framework `cnoe-cli` is capable of extremely limited verification of +artifacts within kubernetes. The same verification is also available as a step +within a backstage +[plugin](https://github.com/cnoe-io/plugin-scaffolder-actions). This is pretty +much just a wrapper of the cli tool. The tool consumes CRD-like structures +defining the state of pods and CRDs and checks for their existence within a +live cluster ([example](https://github.com/cnoe-io/cnoe-cli/blob/main/pkg/cmd/prereq/ack-s3-prerequisites.yaml)). + +Depending on the aspiration of 'verification' this check is rather superficial +and might only suffice as an initial smoke test. Furthermore, it seems like the +feature is not actually used within the CNOE stacks repo. + +For a live product more in depth verification tools and schemes are necessary +to verify the correct configuration and authenticity of workloads, which is, in +the context of traditional cloud systems, only achievable to a limited degree. + +Existing tools within the stack, e.g. Argo, provide some verification +capabilities. But further investigation into the general topic is necessary.