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

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.

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 available in two different variants:

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

AdoptOpenJDK

AdoptOpenjdk are also available:

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

AdoptOpenJDK Wildfly

AdoptOpenjdk with wildfly is available:

baseimages/adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.6_10-wildfly-19
Usage:
Dockerfile
FROM registry.admin.ehealth.sundhed.dk/baseimages/adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.6_10-wildfly-19
ADD your-awesome-app.war /opt/jboss/wildfly/standalone/deployments/

Distroless java

Distroless java images are provided in two different versions:

distroless/java:nonroot
distroless/java17:nonroot

Nginx

nginxinc/nginx-unprivileged:1.21-alpine

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 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 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 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