...
The images can be found on the official eHealth docker repository: https://registry.admin.ehealth.sundhed.dk/harbor/projects/11/repositories
| Table of Contents |
|---|
| Info |
|---|
The following list does not show the newest image tag, these can always be found at the link above. |
...
| Code Block | ||
|---|---|---|
| ||
baseimages/alpine:3.11 |
...
JBoss Wildfly
If you need to run an application server, instead of a standalone java Java application you can use jBoss JBoss Wildfly.
In this case, please use the newest wildfly image that you can.
| Code Block | ||
|---|---|---|
| ||
baseimages/jboss/wildfly:17 |
Azul
OpenJDK are is available in two different variants:
| Code Block | ||
|---|---|---|
| ||
baseimages/azul/zulu-openjdk:11 baseimages/azul/zulu-openjdk:alpine-11 |
AdoptOpenJDK
AdoptOpenjdk are is also available:
| Code Block | ||
|---|---|---|
| ||
baseimages/adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.6_10 |
AdoptOpenJDK Wildfly
AdoptOpenjdk with wildfly is available:
| Code Block | ||
|---|---|---|
| ||
baseimages/adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.6_10-wildfly-19 |
Usage:
Dockerfile
| Code Block | ||||
|---|---|---|---|---|
| ||||
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 Java images are provided in two different versions:
| Code Block | ||
|---|---|---|
| ||
distroless/java:nonroot distroless/java17:nonroot |
Nginx
| Code Block | ||
|---|---|---|
| ||
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
...
and 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 the number of extra components in the image that can contain security issues
Not building any passwords or API keys
in to into the image