coguardio / coguard-cli

The CoGuard CLI Tool
MIT License
92 stars 9 forks source link

COS-285 - Add folder scan to the capabilities. #45

Closed ioah86 closed 1 year ago

ioah86 commented 1 year ago

This is the first re-factoring of the code to enable not just docker image analysis, but also discover files in a given folder.

The new sub-command is activated by

coguard folder-scan <PATH_TO_FOLDER>

If no path is supplied, the current working directory is being used.

This feature will for now be not part of the free offering, although we may revisit this at some point.

The output format and options remain the same as for the Docker image scan.

On the back-end, a cluster named after the folder will be created, and all discovered configuration files will be uploaded there.

davidcrow commented 1 year ago

do you want to call this folder-scan?

coguard scan <PATH_TO_FOLDER>

alternatives: coguard init <PATH_TO_FOLDER> coguard discover <PATH_TO_FOLDER> coguard search <PATH_TO_FOLDER>

For yum it might be list, this could be in

coguard ls-tree <PATH_TO_FOLDER> coguard ls <PATH_TO_FOLDER>

ioah86 commented 1 year ago

Hm, that is an interesting discussion. Right now, we have

coguard docker-image <IMAGE_NAME>

Technically, a discover and scan happens there too.

The question is how to split this up logically the best.

I guess coguard discover {folder|docker-image} would be congruent, but I am not sure if we need the extra word there.

The initial way was for congruency. In later tickets we will also have

coguard cloud-scan <Provider> <region>

or something like that.

The main idea is to stay congruent and not confuse the users.

Another suggestion would be to divide it by keywords

coguard docker-image ...
coguard file-system ...
coguard cloud ...

where the dots are more commands like scan, discover, etc.

Too much text, but this is brainstorming, and I am trying to paint a complete picture here :-)

The issue is

davidcrow commented 1 year ago

Interesting. I think what do users expect, which is hard to know. But we could talk about it from an actual usage, i.e., do users want to see the files before, i.e., generate a file manifest, or do they just want it to happen.

In the Dockerfile/GitHub Actions integration there is the "manifest" that gets added: - run: | curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BEARER" \ -d '{"serviceName": "dockerfile", "serviceKey": "dockerfile_elasticsearch", "version": ""}' \ "https://portal.coguard.io/server/cluster/add-new-service/react-test-app/react-app-container?organizationName=foobar" I wonder if it is command + noun vs command + verb. Command + noun is a list. Command + verb is action.

This lists all of the docker files. coguard list <PATH> (filesystem) coguard docker list <PATH> (all docker images) coguard cloud list <PATH> (all cloud services) coguard aws list <PATH> (only AWS)

ioah86 commented 1 year ago

David and I have sat together and here is the way moving forward, for now.

The general usage is:

coguard <FEATURE-SUBSET> <ACTION> ...

And to start, we will have

coguard docker-image scan ...
coguard folder scan ...
coguard scan
coguard pipeline init ...
coguard cloud scan ...

The docker-image, folder, and cloud feature subsets will default to the scan action, i.e. the usage will not change.

The scan subset will run all scans available in the software.

For this PR, the folder scan mechanism is the focus.