ci: automatically scan and patch our images for known vulnerabilities

[consideRatio]

In this PR I've created a workflow scheduled to run once daily scanning the images we manage with chartpress for known vulnerabilities using aquasecurity/trivy by using the aquasecurity/trivy-action.

Closes #1712.

In this PR also...

• Use GitHub workflow status badges in README.md

In future PRs... (Done in 4728fa2)

• Update Dockerfiles with a comment to trigger rebuilds by the CI system
  • Let the comment contain a hash of some kind, diffing the latest released vulns with the new vulns.
  • Update all Dockerfiles to contain such comment
• Automate practice of forcing a rebuild to see if it resolves security concerns and if so, open a PR to trigger the rebuild.
• Update the PRs to contain reports
• Block this workflow from running on forks randomly disturbing anyone having forked this repo

Example workflow run

[minrk]

Nice! I left a question inline about whether splitting and recombining the image into repo:tag is necessary.

Do we also want to run this scan on PRs that change the image directories?

[manics]

Suggestion for the future? Have chartpress output machine-readable JSON that can be read straight into a GitHub workflow variable. This would be more robust than using grep if more images are added, and means anyone else using chartpress could copy this action 😄.

[manics]

Could we merge this now, and leave the additions (automatic updates) for a follow-up PR? It might make it easier to review, especially if you're going to automatically push branches.

[consideRatio]

@manics ok sure!

[consideRatio]

Here is an example workflow run which i triggered manually thanks to the workflow_dispatch trigger: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/runs/1551355583?check_suite_focus=true

[consideRatio]

I successfully made the vuln-scan workflow automatically open PRs to trigger rebuilds based on if known vulnerabilities were found to be resolved by rebuilding an image. I've also verified it seem to work here in this repo like it did on my fork. See the this run for example.

Since this functionality was built on adding a comment to all our Dockerfile's, it forced a rebuild. So when merged to master some fixes were applied. This means that it may take a while before we see the automation in action in this repo. But, it can be seen in my fork from when I developed it: consideRatio#17.

---

I pushed 4728fa2 straight to master, which was a shortcut to ensure I got this working all the way - right away. If I had opened a PR and self-merged it, it would have provided a better UI for post-merge review/discussion, and it may have been relevant to hold back for additional review to come in. Sorry for the haste. My main worry nudging me to not wait for review of this was to be able to keep focusing to make this work all the way right now when I had the time and focus. I've found myself context switching more than I'd like recently and felt it takes a toll on my focus and productivity. I don't intend to make a habit of it.

[manics]

Thanks, I'll take a look 😄

Is there a benefit to pushing straight to master over opening and self-merging a PR? The benefit of PRs is that it fits in with the workflow for releases where the changelog can be automatically generated, and if there is a problem in future one of the first things I do is scan through the list of PRs.

[consideRatio]

Is there a benefit to pushing straight to master over opening and self-merging a PR?

Not worth doing it for, not in my mind! There are more benefits of having PRs as well, such as grouping related commits

[meeseeksmachine]

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/jupyterhub-helm-chart-0-11-0-released/7521/1