Docker Base Images

Owned by Frederik Mogensen (Unlicensed)
Last updated: 23-09-2024 by Henning C. Nielsen
2 min read



Docker Base Images are the images that all applications running on the Infrastructure must build.

The images can be found on the official eHealth docker repository: https://registry.admin.ehealth.sundhed.dk/harbor/projects/11/repositories

The following list does not show the newest image tag, these can always be found at the link above.

Azul

OpenJDK is available in two different variants:

baseimages/azul/zulu-openjdk:alpine-xx

Used by

Systematic

Distroless java

Distroless Java images are provided in two different versions:

baseimages/distroless/java:nonroot # The newest one baseimages/distroless/javaXX:nonroot # Where XX is the major version e.g. 17

Used by

Trifork

Nginx

baseimages/nginxinc/nginx-unprivileged:x.xx-alpine-slim

Used by

Trifork and Telma

Keycloak

Used by

Trifork

Node

Used by

Systematic

Cosign

Used by

Trifork

Kubectl

Used by

Trifork

Alpine

Used by

Systematic

Security

All docker images are subject to regular security scans. The chosen security scanning software is Trivy which comes with Harbor.

Trivy subscribes to security feeds from the major OS Providers: Alpine Linux, Debian, CentOS as well and NVD.

Both Operating System packages and application libraries are scanned.

If Trivy misses anything, Snyk is scanning inttest and production.

Mitigation

If a critical security issue is found in the docker image the supplier will be notified and needs to take swift action (within 3 hours) to mitigate the issue.

The result will be a new docker image built by the supplier which doesn't contain the issue and needs to be deployed on the infrastructure using the normal CI/CD pipeline.

If non-critical security issues are found in the docker image a report will be generated for the supplier.

Best practices

Suppliers must follow best practices regarding docker images. This includes:

  • Not running processes as root inside the container.

    • This will be enforced by Kubernetes when images are started.

    • Put "USER 1000" or similar into your Docker file, as Kubernetes doesn't support checking non-numeric usernames.

    • Use "COPY --chown=1000:1000 to set sufficient permissions to access files inside the container.

  • Building minimal images, both in regards to actual size and in regards to the number of extra components in the image that can contain security issues

  • Not building any passwords or API keys into the image