Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Current »


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-11
baseimages/azul/zulu-openjdk:alpine-17

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:1.26-alpine-slim

Used by

Trifork and Telma

Keycloak

baseimages/keycloak:25.0

Used by

Trifork

Node

baseimages/node:20-alpine

Used by

Systematic

Cosign

baseimages/cosign:2.2.4-dev

Used by

Trifork

Kubectl

baseimages/kubectl:1.30

Used by

Trifork

Alpine

baseimages/alpine:3.17

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


  • No labels