-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(repo): Simplify structure #308
base: main
Are you sure you want to change the base?
Changes from all commits
2341576
7aecd33
6ae456c
e281ce0
b58a18c
25d4ad7
e7ba465
9afd9ef
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -29,6 +29,19 @@ wget https://github.com/aquasecurity/trivy-checks/raw/main/test/testdata/kuberne | |
conftest test denied.yaml --policy myPolicy/ --namespace builtin.kubernetes.KSV008 | ||
``` | ||
|
||
# Kubernetes checks classification | ||
There are several Kubernetes checks that target various subsystems. They are loosely classified as follows. | ||
|
||
| Target | Description | | ||
|----------------|------------------------------------------------------------------------------------------------------------------------------------| | ||
| Network | Checks primarily targeting the networking stack | | ||
| Dynamic | Checks that evaluate deprecated and removed APIs | | ||
| CIS Benchmarks | Checks that are recommended by the CIS Benchmarks. The checks inside are targeted per each subsystem (e.g. apiserver, cni, etc.) | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If this dir is serving only CIS, and CIS is using only this dir then fine, but I will challange us abit here: aren't these checks valid k8s checks also outside CIS context? aren't CIS reports include k8s checks besides these checks (i presume something like non privileged pod check). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right in the sense that these checks are ordinary checks even outside of CIS context. I'm open to re-organizing all k8s checks in general (maybe based on another type) but we just need to confirm first with the stakeholders that this won't cause any breakage as in the past some users did rely on the structure. Can we do this in another PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes I think we need to reorganize the checks which is part of the motivation for this PR. sure if you think it needs another pr that's fine |
||
| Advanced | Checks that are recommended for the advanced uesrs of Kubernetes | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how do we define advanced users |
||
| GKE | Checks specific to Google Kubernetes Engine | | ||
| PSS | Checks pertaining to Pod Security Standards | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same comment as CIS |
||
|
||
|
||
# Standards and best practices | ||
This GitHub repository has controls that cover both [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) (PSP) and the Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) (PSS), plus additional best practices. | ||
|
||
|
This file was deleted.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
either the description is not accurate or the dir name is bad. I think the intention was that these checks rely on environmental context for evaluation. for example, the deprecated API checks rely on information of which k8s version the user is running/evaluating against in order to decide if outdated or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree the name isn't very meaningful but then again I didn't want to change it in this PR as there maybe users who rely on this structure.
I couldn't come up with a better description, so I'm open to ideas. Would the following work based on what you said?
"Checks whose decision outcome is dynamically determined based on the environmental context."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you think the structure of checks could break users? I mean aren't the checks save/loaded from embedded/bundle in their complete hierarchy? is changing the internal hierachy problemattic?
about the description, it's something like:
"Checks that cannot evaluate based on input alone, and depend on environmental or user-provided context"