Define docker build and deployment lifecycle #23
Description
Probably considerable overlap with other raised issues
We have a set of docker security guidelines from Amir we started from but obviously since then gained some better understanding of what works and what doesn't
Our docker image repo is our artifactory. Artifactory is used both as docker image repo and as build package repo .. meaning if you build your application (Maven?) your should be using Artifactory as transparent proxy between your internal build chain and any external component repo. During your build process Artifactory will cache any modules you pull from a public repo and scan it for vulnerabilities. Subsequent pulls can then be resolved through the cached and ‘locked-in’ version held locally in Artifactory,
This prevents us from being exposed to repo poisoning attacks where malicious code could be inserted in a public repo and inserted in dependent projects by virtue of building them.
We need to be able at any point i time to build a production deployment of X with verified components without the need of an external repo, be it npm, or maven or ‘god-knows-what’. Artifactory as transparent proxy to any public repo will give us this assurance.
Once your CI has finished, you push the docker build into Artifactory. Again we scan for vulnerabilities automatically, If its clean, you can use your CD pipeline to deploy it into production.
Your docker images can be derived from validated images from verified vendors on docker hub. In general that tends to be repos in the root _ namespace of docker hub. Docker has transitioned to use Alpine as base image.
https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
https://hub.docker.com/_/alpine/
Since you are asking for OpenJDK .. there appears to be an official build for that as well
https://hub.docker.com/_/openjdk/
Verified or official docker hub account are labelled as such (labeled official and placed in the root _ namespace - you can use docker pull openjdk in that case - hence the reference to namespace) and are curated and validated by a dedicated team at Docker.
https://docs.docker.com/docker-hub/official_repos/
So in general your CI/CD will split conceptually between two distinct phases …
(1) the source to image build process: the image being generated and pushed into artifactory
(2) the image repo to deployment process: the image being pulled from artifactory and deployed into production