Tools such as Kubernetes are used to deploy an application in the cloud. Kubernetes (also of interest: how to set up Kubernetes in a single click is an open-source system developed by Google for managing container applications. A container in this context is a runtime instance of a (Docker) image.
Docker images consist of various components that are required to run the actual service addressed by the Docker image. Docker images must be constantly updated to fix security vulnerabilities and guarantee a high level of service. Automating the process is advantageous as you can reduce the time between the detection of a security vulnerability and its removal. The process runs completely automatically, which is why it is also called a zero-touch (or no-touch) operation.
Below, a process is described that makes it possible to automatically recognize (within a certain framework) whether an image has security vulnerabilities, and if necessary, to rebuild images.
Docker tags are used to track the version of the service. Once an image is built and stored in a registry, it ages. Although security vulnerabilities may be present in the actual service artifact, security vulnerabilities in the components are much more serious. The security vulnerabilities of components are collected and made publicly available in Common Vulnerabilities and Exposures (CVE) databases. These databases are of great value for finding and fixing security vulnerabilities in one's own libraries. Hackers also use these databases to take advantage of the listed vulnerabilities. Some of the components have been installed millions of times, making them ideal targets. Those who fail to fix the security vulnerabilities quickly will fall victim to automated attacks. Components must therefore be updated continuously.
Once a Docker image has been created, it can only be used in a production environment for six months. A service image, which remains the same version, must always be regenerated in order to use the current versions of the components.
That which applies to the server infrastructure must also apply to Docker images. Patches must be installed continuously. This means that Docker images must be constantly rebuilt.
Challenges when patching Docker images
A frontend image commonly has a kernel/OS layer, a middleware layer, and an application layer. Patches are usually offered from different sources, which means the installed components must be sorted by source. A source for the OS layer might be the Yellowdog Updater, Modified (YUM). If components are installed via YUM during the build process, they can also be updated via YUM. Package management systems such as YUM make the automated updating of components much easier, as they can handle versioning and updating automatically.
Middleware cannot always be shared via a package manager, or may be designed to be installed via a package manager separately from the installation. In order for the middleware to be installed automatically, a wrapper tool must be used which can determine the version of the installed middleware and check whether new versions are available.
Evaluation process
Before an image can be evaluated, a list of all the installed components is saved in the installed version when the image is created. These lists can then be compared with CVE databases and a health score of the image can be calculated. Tools like Trivy can assist with this task very well, or even take it over completely (depending on the design of the workflow).
The evaluation of a component can have four possible outcomes. A package is considered "outdated" when a new version has been released.
If no security vulnerabilities are found during a scan (statuses 3 and 4), then there is no need for action as the new version comes with all the latest updates and features. If vulnerabilities are found but a patch is not yet available for the package (status 1), then the respective employees should be contacted for an individual assessment. For status 2, there is an urgent need for action.
If a component of an image is assigned status 2, then the entire image gets this status.
If an image is assigned this status, a new patch release is built with the updated components.
Conclusion
A "no-touch operation" can only be partially set up for such a system. Essentially, two problems must be solved to achieve complete autonomy. First, the wrapper tool (which checks the components) must be constantly adapted to the deployed components, and second, the components must no longer be patched over time but upgraded to the new major release version. This may result in "breaking changes" that can severely limit the functioning of the service included in the Docker image.
It's not a question of "if," but of "when" a component is no longer patched and must be migrated to the next major release version. For this case, it's difficult to find an automatic solution.
Automated tests (in particular) can help to quickly become aware of a non-functional component in this scenario.
Tools such as ArgoCD can be used for automated deployment in the operation of newly built images.