Hello Selva, Thanks for letting us know the issues! verified we do have issues #1 and #2. issue #1 was introduced (by me) when we moved to hardened docker image, i saw the builds pass and container popping up successfully and thought things are well but looks like no. Issue #2 was a minor annoyance pre JDK17 but looks like it breaks now :(
About the base image, as part of KNOX-3264 we moved to hardened images for Knox to be on top of CVE and patches. This was the primary reason for the move to prevent as much vulnerabilities in Knox as we possibly can. You can look at the details here [1] and pull the image using docker pull dhi.io/eclipse-temurin:17-jdk-debian13-dev We would definitely love (and looking forward to :) ) if you can contribute fixes! Also, thank you for bringing this to our attention! Best, Sandeep [1] https://hub.docker.com/hardened-images/catalog/dhi/eclipse-temurin/images/eclipse-temurin%2Fdebian-13%2Fjdk-17-dev/sha256-999cbe6c363ae24a31f6baa1152eaa610eb7d78671615d8e4c9a8345717a51b8 On Wed, Apr 8, 2026 at 8:44 AM Selvamohan Neethiraj <[email protected]> wrote: > Hi Knox Dev Team, > > I am working on deploying Apache Knox in a Kubernetes (K8s) environment > and have encountered a few issues with the current apache/knox:latest > Docker image. I wanted to check whether others have seen similar problems > and whether there are recommended resolutions. > > Environment: > Kubernetes-based deployment > Using Docker image: apache/knox:latest > > Issues observed: > Issue #1 – keytool path in entrypoint script > The entrypoint.sh script refers to the keytool utility using a fixed path > (/usr/bin/keytool). > However, in the container environment, the Java keytool is located in a > different directory and not under /usr/bin. This causes failures during > initialization. > > Issue #2 – Keystore password length > The password used to protect the keystore files appears to be too short > (default appears to match MASTER_SECRET). > This causes the keytool utility to fail during keystore generation due to > password length requirements. > > While investigating and attempting to fix the above issues directly from > the source repository, I encountered an additional concern: > Issue #3 – Base image accessibility > The Docker build references the base image: > dhi.io/eclipse-temurin:17-jdk-debian13-dev > I was unable to access this image. Is there a specific reason for using > this base image instead of the standard: eclipse-temurin:17-jdk > > If others have encountered similar issues while running Knox in > Kubernetes, I would appreciate any guidance or recommended fixes. > > If these are confirmed issues, I would be happy to contribute patches to > address them. > > Thanks, > Selva > >
