When running applications under a PaaS solution, such as Azure App Service plans we don’t have to worry about patching the underlying operating system or the version of .Net.

When our application run inside docker containers however, we need to ensure that the base image is kept up to date to address any security vulnerabilities. In this post, we will look at some of the ways we can keep our base images up to date and stay secure.

.NET Base Images

Microsoft provide a number of base container images that we can use to run our .NET applications.

These images contain both a base operating system and the .NET runtime, meaning updates and patches to either need to be then rebuilt into our container images. Updates are provided regularly rather than on a fixed schedule to include the latest security patches as quickly as possible. With this in mind I started to look for a solution to best keep my images up to date.

Image Update Policy

• Base Image Updates: Images are re-built within 12 hours of any updates to their base images (e.g. debian:bookworm-slim, windows/nanoserver:ltsc2022, etc.).
• .NET Releases: Images are re-built as part of releasing new .NET versions. This includes new major versions, minor versions, and servicing releases.
• Critical CVEs: Images are re-built to pick up critical CVE fixes as described by the CVE Update Policy below.
• Monthly Re-builds: Images are re-built monthly, typically on the second Tuesday of the month, in order to pick up lower-severity CVE fixes.

Source: .NET Container Images - Image Update Policy

Copacetic

When I started asking others how they would approach the issue of keeping base images up to date, Copacetic was often mentioned. Copacetic looks a really interesting project. Instead of rebuilding your entire Docker image, it will patch it, reducing the time to update the image.

However when I read the FAQ at this time Copacetic is only capable of patching vulnerabilities in the operating system. This means it would not include any changes in .NET so would not be suitable for keeping .NET base images up to date on it’s own.

Copa is capable of patching “OS level” vulnerabilities. This includes packages (like openssl) in the image that are managed by a package manager such as apt-get or yum. Copa is not currently capable of patching vulnerabilities at the “application level”

Source: Copacetic FAQ

Scheduled Builds

One approach to keeping base images up to date is to schedule a build. You could choose to do this daily or align with the monthly rebuilds of the .NET images. In doing however, so you may miss out on critical CVE fixes.

This approach is simple to implement but would mean we are either building too frequently or not frequently enough. Although we could add more custom logic to the pipeline to check for updates, this would add complexity.

Azure Container Registry Tasks

Azure Container Registry (ACR) has a feature that seems to be designed for this exact scenario. Azure Container Registry Tasks allow you to run a task that will rebuild your image triggered automatically when a base image is updated. This is not a new feature but is hidden away deep in the ACR documentation.

Prerequisites

For this to work you will need to setup the following:

• An Azure Container Registry to host the built image and ACR task
• A GitHub repository to hold the code, as the ACR task needs to be able to rebuild the image from the source.
• A Github Access Token to connect the ACR to the code.

Note that the new GitHub fine-grained access tokens do not work with the ACR at the moment so you will need to use the Token (classic) option and grant it repo level permissions.

Creating an ACR Task

We then need to create the task that will link to the code in GitHub and trigger a build. This task will trigger on either a code change or the base image being updated.

This task must be created on a commandline and cannot be done in the Azure Portal. In this sample code my Azure Container Registry is called blueboxes and the task is called container-demo. You will need to replace them with your own values and add in an access token.

az acr login --name blueboxes
az acr task create `
    --registry blueboxes `
    --name container-demo `
    --image container-demo:latest `
    --arg REGISTRY_NAME=blueboxes.azurecr.io `
    --context https://github.com/blueboxes/acr-container-demo.git#main `
    --file Dockerfile `
    --git-access-token TOKEN

Once created you can see this task in the Azure Portal under Azure Container Registry and then Tasks.

In the portal the icons represent that the base images are being monitored and the task will be triggered when they are updated. If you wish to trigger the task manually at any time you can do this with the command az acr task run -n container-demo -r blueboxes again replacing the task name and acr name with your own.

Result

All task runs can be viewed in the Azure Portal under the Runs tab. You can see the logs of the task run, the reason for the run and the status of the build.

More Information

The docker image I am using in this post is a simple .NET 8 MVC application with a nightly base image, which can be found on my GitHub Account if you wish to try it out yourself.

Azure Container Registry Tasks work on both Windows and Linux. These are priced for each minute the task is running however are relatively cheap.

More information on Azure Container Registry Tasks for base images can be found on the Microsoft learn site along with an official tutorial - Trigger Image Build on Base Image Update in Azure Container Registry

Conclusion

Keeping base docker images up to date is important to ensure that your applications are secure. There are a few ways to keep base images up to date, but the best approach I found is to rebuild the image when the base image is updated. Azure Container Registry Tasks is a great way to automate this process.

Title Image by Tom Majric from Pixabay