Open bitkeks opened 5 months ago
Extracted from #659 as info:
On the other hand, Trivy operator has more capabilities and provides different fine grained reports. As for now, we configured it to generate five reports with information of the current state of the cluster:
Vulnerability Report Sbom Report ConfigAudit Report Exposed Secrets Report Cluster Vulnerability Report
We discussed today that the trivy-dojo-report-operator will be tested to be deployed beside the Trivy operator. This way, the operator's reports are automatically pushed into DefectDojo.
This way, we do not need to run a Zuul pipeline to fetch Trivy Operator reports and upload them to DefectDojo.
The advances of this week have been the following:
1- We have been working on integrating the new operator, which will allow us to send 5 Tirvy Operator automatic reports to Defect Dojo. 2- We are also looking to adapt the execution of the Trivy Operator to less time and thus maintain a greater degree of supervision of the infrastructure. 3- We are evaluating the possibility of having the possibility of changing the execution time of the Trivy Operator, so that the Docker version of the Operator can be used for everything without the need to be executed in the pipeline, and have a more automated way of scanning for vulnerabilities.
Currently the Trivy-reporter is sending the reports as desired, and it is working as required at the beginning, we are working on the details concerning tags, engagements and products, so that there is a coordinated organization of the reports within defect dojo.
Documentation for this both Operator is done
@Spectertj please link the docs and produced code, also for the S3 storage, here - want to review the setup and test it in gx-scs 👍
The cronjob has been created to be able to manage and upload the reports generated by the Trivy Operator, these reports will go in a bucket in OpenStack. Two scripts have been created, one to obtain the reports and the other to be able to upload them to OpenStack
Python script migrated to sh script because there are some missing libraries
@Spectertj please ping @gtema to test the upload in S3/Swift
@Spectertj what's the status here?
@Spectertj as discussed:
The requested adaptation has been made to use Kubernetes secrets that would be previously handled at the time of the deployment of the tools, the adaptation has also been made so that the container can be used with OSC (open stack client) which with said credentials extracts directly from the secrets and uses them to connect to open stack and upload the report files.
We have also proceeded to document what the expected result of each report is, because the process we carry out is done the way it is done.
The flow followed by the tool has been documented a little more.
I focus on improving documentation processes by thoroughly analyzing existing materials, identifying gaps, and updating or creating new documentation to ensure clarity, accuracy, and usability. This involves standardizing formats, enhancing descriptions, and incorporating visual aids for better comprehension.
Additionally, I design and develop detailed workflow diagrams to illustrate the process of executing software for acquiring and storing reports. These diagrams serve as visual representations of complex processes, outlining each step from initialization to final storage.
As a CSP, I want to continuously scan my container infrastructure for security weaknesses so that I can prevent security gaps in my Kubernetes clusters.
This issue focusses on the Trivy Operator which is deployed in CaaS clusters and runs continuously. The reports are uploaded to DefectDojo.
ping @90n20
The one-time run of Trivy in the Zuul k8s security pipeline is contained in #659.