2.8 KiB
| title | weigth | description |
|---|---|---|
| Validation and Verification | 100 | How does CNOE ensure equality between actual and desired state |
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, 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
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. 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).
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.