Joseki is a set of services to help you keeping cloud-infrastructure, kubernetes and docker-images configuration closer to known best-practices.
At the moment, the project integrates three open-sourced tools:
- Container Image vulnerabilities scanner trivy.
- Kubernetes objects validator polaris.
- Azure Cloud infrastructure auditor az-sk
More information about product motivation, what it is, and roadmap is at the Product overview document.
Joseki web application provides a visual overview of the audited infrastructure:
- a summary of the overall infrastructure state at any given date

- comparison of a single infrastructure component state at two given dates

- docker image scan overview

- filterable table with all check results for a given date

- check-results history, component-details pages for each separate infrastructure component, and others.
Joseki consists of three main parts:
frontend- a web application, which interacts with end-user;backend- exposes web-api forfrontendand does the most of business logic: shaping audit data, historical view, reporting, configuration.scanners- a set of applications (one per audit/scan type), that once in a while perform audit/scan operation and uploads raw results to a Blob Storage.
The first version of Joseki works with trivy, polaris, azsk scanners, and consumes Azure-hosted components:
More technical details you could find in the Technical design document.
You can deploy the product to your infrastructure using the Deployment guide. If you need help or have questions – open github issues, contact us via joseki@deepnetwork.com or individual contributors.
We would ❤️ to hear your feedback, so you are welcome to share your thoughts and views!
Unfortunately, not. Joseki's task is to reveal the actual state of the system and compare it over time. For CI/CD, we would suggest looking at scanners itself: polaris, trivy, azsk.
Once a scanner completed the audit/scan task - it uploads results to Blob Storage. When backend finished processing raw results - it moves files to Archive.
Scanners follow the /{scanner-type}-{scanner-id-short-hash}/{audit-date}-{hash}/{audit_files} pattern to create audit folders. For example:
Results might get lost, in two places:
scannerfailed to perform the audit itself. To check it, take a look at scanner logs;backendfailed to parse scan results. In such a case, dive intobackendlogs for clues.
Also, you can check raw audit results at blob storage. meta file in the audit folder describes the result of the audit: failed, succeeded, and the scan related metadata.

