Skip to content

Fix the Docker image build and run OpenAS2 in it as a non-root user - #637

Open
JakeHuneau wants to merge 1 commit into
OpenAS2:masterfrom
JakeHuneau:fix/docker-java17-non-root
Open

JakeHuneau wants to merge 1 commit into
OpenAS2:masterfrom
JakeHuneau:fix/docker-java17-non-root

Conversation

@JakeHuneau

Copy link
Copy Markdown
Collaborator

Closes #367.

Problem

The image doesn't build. The Dockerfile uses eclipse-temurin:11 for both stages, but since #593 the project compiles for Java 17 (<java.version>17</java.version>). The build stage fails:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile)
on project openas2-server: Fatal error compiling: error: invalid target release: 17

And it runs as root (#367). That matters for a service that is normally exposed to the internet.

Change

  • Java 21: both stages use eclipse-temurin:21 (jdk for building, jre at runtime). That's the newer LTS release, and CI already tests it.
  • Non-root user: the server runs as the user openas2, with numeric UID 1000, so Kubernetes can verify runAsNonRoot, in group 0.
  • Arbitrary UIDs: everything under /opt/openas2 is owned by that user and is group writable. Platforms that run containers under an arbitrary UID in group 0 work too.
  • Docs:
    • README: the ownership volumes need, how to fix it, and how to keep running as root while migrating. It also corrects the image's environment block, which still listed Tomcat paths and Java 11.
    • k8s-deployment.md: the example deployment sets a pod securityContext, with a note that Azure Files / SMB / NFS volumes ignore fsGroup and need mount options instead.
    • RELEASE-NOTES.md: an upgrade note.

Upgrade impact

A volume owned by root isn't writable by the new user. An existing deployment whose config or data volume was created by root will fail to start with Permission denied until it does one of these:

  • chown -R 1000:0 the volumes, or
  • set fsGroup in Kubernetes, or
  • keeps running as root with docker run --user 0 / user: "0".

That's what the upgrade note covers.

Verified with the built image

  • Builds, including the test suite that runs during mvnw package.
  • Java is PID 1 and runs as uid=1000(openas2) gid=0(root). OpenAS2 Server v4.14.0 started.
  • An empty config folder is populated from the template, owned by the new user.
  • docker stop shuts down cleanly in 2 seconds ("All work in progress finished before shutting down").
  • A new named volume is created as 1000:0 and the server starts.
  • A root-owned bind mount fails with Permission denied, and starts with either --user 0 or after chown 1000:0.

Dockerfile_WebUI is unchanged.

The Dockerfile built on eclipse-temurin 11, but since the minimum Java version
was raised the project compiles for Java 17, so "docker build" failed in the
build stage with "invalid target release: 17". Both stages now use
eclipse-temurin 21, the newer LTS release CI already tests.

The server also ran as root inside the container (issue OpenAS2#367), which matters
for a service that is normally exposed to the internet. It now runs as the
user "openas2" with the numeric UID 1000, so Kubernetes can verify
runAsNonRoot, in group 0. Everything under /opt/openas2 is owned by that user
and group writable, so platforms that run containers under an arbitrary UID in
group 0 work too.

A volume owned by root is not writable by the new user, so an existing
deployment whose config or data volume was created as root fails to start
with "Permission denied" until it is changed. The README now explains the
ownership needed and how to keep running as root while volumes are migrated,
the Kubernetes guide's example sets a pod securityContext, and the release
notes carry an upgrade note. The README's description of the image's
environment, which still gave Tomcat paths and Java 11, is corrected.

Verified with the built image: the server runs as uid 1000 and starts, the
config template is copied into an empty config folder, docker stop shuts it
down cleanly, a named volume is created with the right owner, and a
root-owned bind mount fails as described and starts with either fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Avoid running as root

1 participant