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 9 Next »

All applications running on the Infrastructure must build upon one of the given docker base images.

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.

OpenJDK 

baseimages/openjdk:11-jre-slim

Or if you wish to use a minimal JRE for the developed application you can use jlink to create this.

And run the resulting on

baseimages/alpine:3.11

jBoss Wildfly

If you need to run an application server, instead of a standalone java application you can use jBoss Wildfly.

In this case, please use the newest wildfly image that you can.

baseimages/jboss/wildfly:17

Azul

Openjdk are avaible in two different variants:

baseimages/azul/zulu-openjdk:11
baseimages/azul/zulu-openjdk:alpine-11

AdoptOpenJDK

Openjdk are also avaible:

baseimages/adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.6_10

Security

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

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

Both Operating System packages and application libraries are scanned.

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 Dockerfile, 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 number of extra components in the image that can contain security issues
  • Not building any passwords or API keys in to the image


  • No labels