The runAs user displays "i have no name"

HiveMQ Commercial Offerings HiveMQ k8s Operator
1

with k8s opertator, which uid should be used for the runAs user for hivemq cluster?

pspEnabled: false
pspAnnotations: {}
securityContext:
  runAsNonRoot: true
  runAsUser: 1000

podSecurityContext: {}
# fsGroup: 10000
# runAsNonRoot: true
# runAsUser: 10001

in Pod:
I have no name!@hivemq-85fd4bb459-7qxmq:/opt/hivemq-4.24.0$
I have no name!@hivemq-85fd4bb459-7qxmq:/opt/hivemq-4.24.0$
I have no name!@hivemq-85fd4bb459-7qxmq:/opt/hivemq-4.24.0$

2

Hello @hivemq

Thank you for reaching out and joining our Community Forum.

Experiencing the “I have no name!” message is not considered an issue; however, it is often associated with the configuration of the user inside the container. This typically happens when the assigned UID (User ID) lacks a corresponding entry in the /etc/passwd file.

To address this, creating a custom image through a Dockerfile and configuring it can be a helpful solution. This allows for the proper setup of user configurations and mitigates the occurrence of the “I have no name!” message.

We hope this helps.

Regards,
Sheetal from the HiveMQ Team

3

Thanks for your detailed explanation.
We found that the offical default image “k8s-4.x” has a build-in user Hivemq with UID 10000 in /etc/passwd, but the default runAsUser UID configued in values.yaml is 1000. It would be nice if the small defects can be fixed offically.
Thansk again!

4

Thanks for reporting it @hivemq!
We are already aware of this issue, and we are aiming to fix it in the new Platform Operator.

Cheers

5

Thank you. @Antonio

Although we can find an example Dockerfile from helm-charts/examples/hivemq-operator/example_nonroot_k8s.dockerfile at master · hivemq/helm-charts · GitHub, which can be used to rebuild a new image with non-root user and group.
However, it hasn’t been updated for a long time, and we’re concerned about whether it is still compatible with the latest version of the official image, e.g. the JAVA_IMAGE version.

6

You’re right, that Dockerfile image example you’re pointing out hasn’t been updated in a long time. However, that image is used as an example to build a non-root Docker image, extending/using as a base image our [k8s-4.8.3] used for the legacy operator. So it is still valid to be used with the legacy operator as an example of a non-root user, and with that Java base image (we currently using Java 11 so no issues there).
For instance, that particular image is use in some of the integration tests we have in place, and you can see in some of the latest PR it still works. See here - where that tar file is built from that particular image when running the tests here.

However, it is true, that in this tests is using the same HiveMQ Operator image version k8s-4.8.3, and that’s something we have to improve as well. So take that Docker image example just as what it is, an example. It may not necessary work for newer Docker Operator legacy images.

On the other hand, the new Platform Operator supports also running the Docker image as a non-root, so feel free to give it a try, as it should be the right way to go rather than the legacy operator.

7

Appreciate！ Since this is not considered a problem and doesn’t affect the HiveMQ service running, we’ll just wait to upgrade to the new version of the operator.
As the document notes, the new operator only supports HiveMQ 4.19 or above. currently, we’re on 4.9.x. :laughing: