70 lines
2.8 KiB
Markdown
70 lines
2.8 KiB
Markdown
|
---
|
||
|
|
title: Validation and Verification
|
||
|
|
weigth: 100
|
||
|
|
description: 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](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.
|