docs: Update proposal 2 with design changes #143
Conversation
Signed-off-by: Ross Fairbanks <[email protected]>
| In the example above, the Kubernetes manifest that is applied to the cluster is located in a different repository: this is the case of an externally defined benchmark | ||
|
|
||
| Each workflow should ensure that any artefacts that were deployed as part of the benchmark job should be deleted at the end of the test run. | ||
| Manifests in `project.json` are pinned to a Git commit SHA rather than a branch such as `main`. This mitigates the risk that a malicious workload could be included in the benchmark manifest and ensures that any changes to the manifests are reviewed by one of the Green Reviews maintainers. |
There was a problem hiding this comment.
@leonardpahlke @nikimanoledaki @dipankardas011 FYI I added this note on pinning manifests to SHAs following our discussion in last weeks meeting.
LMK if more detail is needed
There was a problem hiding this comment.
I think we should add some seccomp profiles, quota limits on the namespace we are dealing with so that we don't have impact on other monitoring workloads, also we should perform some sort of image scaning before begining to start benchmarking to safeguard from any potential problems
anyways let me know your thoughts :)
I was just checking out CIS benchmark for any k8s cluster
There was a problem hiding this comment.
@dipankardas011 Those are good recommendations for securing the cluster but I think we should keep this focused on the pipeline.
The future of the cluster is uncertain. If we only provision on-demand the design is likely to be different to a permanent cluster even a single node one. So I would not invest time until the design is clear.
However your approach of being guided by the CIS benchmark is sound. It's also a good point that by running both the project components and the benchmarks in the benchmark namespace we can restrict its access.
|
Sorry I closed the wrong PR 🤦♂️ |
What type of PR is this?
kind/documentation
What this PR does / why we need it:
Updates proposal 2 with design changes implemented in #127
Which issue(s) this PR fixes:
Fixes #117
Special notes for your reviewer (optional):
Changes are quite big so sorry the diff is hard to follow.
I also changed the diagram to mermaid based on the diagram @dipankardas011 added to proposal 1.