Default upload of scan results should be opt-in

[ghost]

I want to preface this issue as, I think kubescape is a pretty nice and nifty tool. It's especially useful for finding misconfigurations in k8s clusters, pods, containers, etc. But, I also want to say that --results-locally should not be opt-in. If you want to provide a consulting tool that people can use as a pipeline for professional services, fine, but do not mask the tool behind such behavior after the fact.

Every single person that executes this tool with kubescape scan framework nsa effectively uploads all their cluster vulnerabilities and issues to ARMO. The fact that someone has to open an issue with a poor default makes me question the actual motivations and desires of ARMO.

The default of this tool being opt-in should be a lesson to anyone using this tool and any other future open source tools that scan systems for security.

[chmod-777-shauli]

Hi @withernet,

As you nicely noted in your note about the expected response, indeed any data that is sent to us is kept safe and is not used by ARMO at any form :-). ARMO is a security company working with large Fortune 500 companies with runtime security products who are also protecting our backend and servers according to all standards.

It is important for us to note that the motivation of this is to enable our users to see and manage their result once they sign in without needing to re-run kubescape again. We do believe you raise a good point about the default usage and making it clear to the users, we tried to do it in the product usage documentation as clear as possible but if you did not see it, we need to take another look at it and consider changing it.

I want to make sure you are aware of the fact that you can use the --results-locally flag to avoid this behavior (Without taking away from your note about the default behavior and what it should be)

We hope this makes sense and are welcoming any feedback and advice and we will look at the best adjustments we can make to assure Kubescape users fee l comfortable with the tool while also getting as much value as possible.

[ghost]

Hey @chmod-777-shauli yep completely understandable.

What I don't like is that I was unaware of this behavior after the fact (and inadvertently submitted a report); and I would bet others have done this too? A couple of different methods while still providing the same functionality are below:

• Write the information out locally, and use a kubescape submit to submit the report.
• Instead of default submit, maybe kubescape scan framework nsa --submit

[levsha]

This default behaviour was also unpleasant surprise for me.
You claim that you keep this data according to all (unnamed) standards, but sorry, this is just your claim. That has to be still users decision to trust you this data or not.
And it can be done trivially: just ask the user!
Doing this by default, without asking the user, and just informing them post-factum gives very bad smell, especially when it comes with the tool that is about security.
It is especially bad that you don't provide any information about how long this data will be stored, will it be also used for anything else (like some statistics), and don't even provide the way to delete this data.

[chmod-777-shauli]

@levsha and @withernet ,

Your point is well taken, and we completely understand. We were under the impression that giving an option to not upload which is fully documented is enough, but it seems it is not clear enough for users, and we need to adjust it.

Therefore, the upload behavior will be changed in the next release, you both gave good ideas as to how to go about it and we highly appreciate it.

[ghost]

Just confirmed this is fixed, thanks guys!

[laurentiuspurba]

@withernet When you said it's fixed, does it mean the following command will not send any report to whatever endpoint that kubescape configured before?

kubescape scan framework nsa --exclude-namespaces kube-system,kube-public --use-from /tmp/nsa.json

I totally agree with you @withernet , the default should be to NOT sending any information to other party.

[ghost]

@laurentiuspurba I tested with strace and wireshark and did not see any connection attempts to armo. However, I do see connection attempts to github-releases.githubusercontent.com which may be where the tool downloads the content to perform its scan (I did not scan with --use from /tmp/nsa.json)?

[leonidsandler]

@withernet When you said it's fixed, does it mean the following command will not send any report to whatever endpoint that kubescape configured before?

kubescape scan framework nsa --exclude-namespaces kube-system,kube-public --use-from /tmp/nsa.json

I totally agree with you @withernet , the default should be to NOT sending any information to other party.

The default behavior of this command is NOT sending any information, just as you expected. The exception to this case is if the user has registered to the SaaS service previously. We did not change the pre-existing behavior for the users who used to run this command and saw their data in the SaaS service. If you are a registered user and you wish to avoid sending your data for specific run, please use --keep-local flag.

[leonidsandler]

@laurentiuspurba I tested with strace and wireshark and did not see any connection attempts to armo. However, I do see connection attempts to github-releases.githubusercontent.com which may be where the tool downloads the content to perform its scan (I did not scan with --use from /tmp/nsa.json)?

Indeed, if you don't use --use-from flag, kubescape will download the latest version of the scanning framework from the GitHub. We strongly recommend to update scanning framework, even if you need to use this flag. We continuously extend and improve the frameworks. Note the latest CVE-2021-25742 test addition that was done in several hours after the publication of the vulnerability.

[laurentiuspurba]

@leonidsandler @withernet Thank you for clear this thing up.
I had to use --use-from flag, cos I got an error while issuing kubescape scan framework nsa command without first downloading the nsa.json file.

▶ kubescape scan framework nsa --exclude-namespaces kube-system,kube-public
error: failed to download file, status code: 403 Forbidden
ARMO security scanner starting
[progress] Downloading/Loading framework definitions
kind: Framework, name: nsa, error: failed to download file, status code: 403 Forbidden

[dwertent]

Hi @laurentiuspurba and thank you for your feedback.

As i'm replying to you I'm working on fixing this issue, in the mean time you can follow the instructions provided here

If you do not have the framework cached, you can download the release running ->

curl -L  https://github.com/armosec/regolibrary/releases/latest/download/nsa -o nsa.json

And then run ->

kubescape scan framework nsa --use-from nsa.json

[george-obr2p]

Hi every one.
Seems that kubescape still sends data as default.
I've run it with the following command:

kubescape scan --enable-host-scan > ~/kubescape_report.txt

Then I get results like
You can see the results in a user-friendly UI, choose your preferred compliance framework, check risk results history and trends, manage exceptions, get remediation recommendations and much more by registering here:

[dwertent]

@george-obr2p Is this the url in the end of the message: https://portal.armo.cloud/cli-signup? If so, the data is not submitted
Is this your case are that you see a different url?

[george-obr2p]

@dwertent yes, also there is this similiar url in the end of the message,
also I can see data there
https://portal.armo.cloud/risk/<my-cluster-name>

I've tried to delete data in portal.armo.cloud, reinstall kubescape from scratch on my device.
Still it pushes data to portal.armo.cloud

[dwertent]

@george-obr2p By default kubescape does not submit your data, but if you submitted your data once, by default kubescape will submit your data next runs also if you do not explicitly add the --submit flag.
If you wish to no longer submit your data, you can ether scan with the --keep-local flag or delete the kubescape configmap (in your default namespace) and the config file ~/.kubescape/config.json