refactor(repo): Simplify structure #308

simar7 · 2025-01-04T05:27:11Z

Simplify specs structure
Document k8s checks
TODO: Should commands/ live somewhere else? They're used by k8s node-collector (see comment refactor(repo): Simplify structure #308 (comment))

nikpivkin · 2025-01-10T10:53:00Z

pkg/specs/loader.go

-const ComplianceFolder = "compliance"
+// Loader access compliance specs
+type Loader interface {
+	GetSpecByName(name string) string


Is there a need for this interface?

Probably not but since we already have it, removal of it would be a breaking change that I don't want to make in this PR.

go.mod

simar7 · 2025-01-15T05:22:11Z

@itaysk for your review: do you want to keep node-collector commands in this repo? I don't think that feature was fully implemented and as a result there's most likely no consumer of this. I personally would move them out elsewhere as they're not checks per-se (maybe trivy-operator?)

ARCHITECTURE.md

itaysk · 2025-01-17T06:59:26Z

ARCHITECTURE.md

@@ -7,10 +7,9 @@ This document aims to answer the question *Where is the code that does X?*
 The directory structure is broken down as follows:

 - `cmd/` - These CLI tools are primarily used during development for end-to-end testing without needing to pull the library into trivy/tfsec etc.
- `checks` - All of the checks are defined in this directory.
+- `checks` - All the checks are defined in this directory.
 - `commands` - All Node-collector commands are defined in this directory.


let's link to node collector docs to make sure the context is undestood

Do we want to continue developing node-collector and its associated functionality? I asked it here.

If not we should remove it from trivy-checks if this repo is solely for the purposes of keeping checks.

yes, node collector is needed for k8s cis compliance, isn't it? in any case, "commands" is not very clear without this context. "node-collector" or something similar will give it more context I think

ARCHITECTURE.md

itaysk · 2025-01-17T07:10:26Z

ARCHITECTURE.md

 - `commands` - All Node-collector commands are defined in this directory.
- `pkg/spec` - Logic to handle standardized specs such as CIS.
- `pkg/rules` - This package exposes internal rules, and imports them accordingly (see _rules.go_).
+- `pkg/rules` - This package exposes internal checks, and imports them accordingly (see _rules.go_).
 - `specs/` - Standaridized compliance specs such as CIS.


I think specs is oerloaded term. for a newcomer "specs" probably relate more to bdd specs or to standardidation specs. the feature in trivy is called "compliance" shouldn't the directory be called that way too?

theres a doc about contributing compliance specs under docs/compliance.md. it's the only doc in the docs dir I thin we should make it a readme in this dir, like kubernetes related info is documented in readme under checks/kubernetes, then we can remove /docs, which should be in trivy anyway

I see that you've addressed the first comment about renaming specs to compliance but not the second about docs

itaysk · 2025-01-17T07:25:21Z

checks/kubernetes/README.md

+| Target         | Description                                                                                                                        |
+|----------------|------------------------------------------------------------------------------------------------------------------------------------|
+| Network        | Checks primarily targeting the networking stack                                                                                    |
+| Dynamic        | Checks that evaluate deprecated and removed APIs                                                                                   |


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.

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."

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"

itaysk · 2025-01-17T07:29:32Z

checks/kubernetes/README.md

+|----------------|------------------------------------------------------------------------------------------------------------------------------------|
+| 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.)   |


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).

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?

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

itaysk · 2025-01-17T07:30:16Z

checks/kubernetes/README.md

+| 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.)   |
+| Advanced       | Checks that are recommended for the advanced uesrs of Kubernetes                                                                   |


how do we define advanced users

itaysk · 2025-01-17T07:30:38Z

checks/kubernetes/README.md

+| CIS Benchmarks | Checks that are recommended by the CIS Benchmarks. The checks inside are targeted per each subsystem (e.g. apiserver, cni, etc.)   |
+| Advanced       | Checks that are recommended for the advanced uesrs of Kubernetes                                                                   |
+| GKE            | Checks specific to Google Kubernetes Engine                                                                                        |
+| PSS            | Checks pertaining to Pod Security Standards                                                                                        |


same comment as CIS

itaysk · 2025-01-17T07:33:06Z

pkg/specs/loader.go

shouldn't this be in trivy?

Not quite because then users will need to import trivy as a library to load compliance specs which isn't ideal as it's a much bigger dependency.

users needing to load compliance checks will also need to run them, which will require trivy no? is there a use case for loading compliance and not running them?

nikpivkin · 2025-01-23T12:58:44Z

pkg/spec/spec.go

@@ -1,23 +0,0 @@
-package spec


Maybe we should leave this package with public functions, which will be imported from pkg/compliance . Then in Trivy you can change the import spec to compliance and after that completely remove this package? This will get rid of the errors.

simar7 added 4 commits January 3, 2025 21:37

refactor(specs): Simplify structure for specs

2341576

add k8s checks readme

7aecd33

update architecture.md

6ae456c

update go mod

e281ce0

simar7 force-pushed the refactor-structure branch from ad52a3f to e281ce0 Compare January 4, 2025 06:44

simar7 requested a review from nikpivkin January 7, 2025 01:32

nikpivkin reviewed Jan 10, 2025

View reviewed changes

nikpivkin mentioned this pull request Jan 10, 2025

refactor: use trivy-checks/pkg/specs package aquasecurity/trivy#8226

Merged

7 tasks

nikpivkin reviewed Jan 10, 2025

View reviewed changes

go.mod Outdated Show resolved Hide resolved

simar7 and others added 2 commits January 14, 2025 22:05

Merge branch 'main' into refactor-structure

b58a18c

go mod tidy

25d4ad7

simar7 marked this pull request as ready for review January 15, 2025 05:15

Merge branch 'main' into refactor-structure

e7ba465

itaysk reviewed Jan 17, 2025

View reviewed changes

rename pkg/specs -> pkg/compliance

9afd9ef

nikpivkin reviewed Jan 23, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor(repo): Simplify structure #308

refactor(repo): Simplify structure #308

simar7 commented Jan 4, 2025 •

edited

Loading

nikpivkin Jan 10, 2025

simar7 Jan 15, 2025

simar7 commented Jan 15, 2025

itaysk Jan 17, 2025

simar7 Jan 17, 2025

itaysk Jan 24, 2025 •

edited

Loading

itaysk Jan 17, 2025

itaysk Jan 17, 2025

simar7 Jan 17, 2025

itaysk Jan 24, 2025

itaysk Jan 17, 2025

simar7 Jan 17, 2025

itaysk Jan 24, 2025

itaysk Jan 17, 2025

simar7 Jan 18, 2025

itaysk Jan 24, 2025

itaysk Jan 17, 2025

itaysk Jan 17, 2025

itaysk Jan 17, 2025

simar7 Jan 18, 2025

itaysk Jan 24, 2025

nikpivkin Jan 23, 2025

refactor(repo): Simplify structure #308

Are you sure you want to change the base?

refactor(repo): Simplify structure #308

Conversation

simar7 commented Jan 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simar7 commented Jan 15, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

itaysk Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simar7 commented Jan 4, 2025 •

edited

Loading

itaysk Jan 24, 2025 •

edited

Loading