以root用户运行Eclipse Temurin等OpenJDK镜像是否安全？Azure K8s集群环境下的用户选择问询

Great question—sticking to non-root users for containers is a core security best practice, so it’s totally valid to question why the Temurin examples default to root. Let’s break down your two questions:

1. Is running Eclipse Temurin (OpenJDK) images as root safe? #

Short answer: It’s not ideal, and carries unnecessary security risks, even though the official Temurin images are well-maintained and free of known malicious code. Here’s why:

• Container escape vulnerability surface: If an attacker manages to compromise your Java app (e.g., via a remote code execution flaw), having root access inside the container makes it far easier to exploit further vulnerabilities to escape to the host system.
• Accidental host damage: If you mount host directories (like configs or logs) into the container, a root user can accidentally modify or delete critical host files—something a non-root user couldn’t do.
• Violates least privilege: Java applications rarely need root-level permissions to run. They typically just need read access to their own code, write access to logs/temp directories, and network access. Running as root gives way more permissions than necessary, which is a bad security habit.

That said, if you’re running a throwaway test container locally, the risk is minimal—but for production (especially in Kubernetes), you should avoid root.

2. Which user should I use in Azure Kubernetes if root is unsafe? #

You have two main options, but one is far better for most production cases:

Option 1: UID 65534 (nobody user) #

This is a built-in, unprivileged user available in most Linux base images.

• Pros: No need to modify your Dockerfile—you can just add USER 65534 to your docker run command or set securityContext.runAsUser: 65534 in your AKS deployment manifest.
• Cons: The nobody user has extremely limited permissions. Many Java apps need to write to /tmp (for temp files), log directories, or even their own config folders, and nobody might not have write access to these locations. This can lead to runtime errors or your app failing to start entirely.

Option 2: Create a dedicated non-root user (Recommended) #

This is the best approach for production because it lets you tailor permissions exactly to your app’s needs, avoiding the pitfalls of the nobody user. Here’s how to set it up:

1. Update your Dockerfile to create a dedicated user and set proper ownership:

   FROM eclipse-temurin:17-jdk-jammy
   # Create a group and user for our app
   RUN groupadd -r appgroup && useradd -r -g appgroup appuser
   # Copy your app files and set ownership to the new user
   COPY --chown=appuser:appgroup my-app.jar /app/
   # Switch to the non-root user before running the app
   USER appuser
   CMD ["java", "-jar", "/app/my-app.jar"]
   

2. In your Azure AKS deployment, you don’t need to override anything unless you want to explicitly enforce the user via securityContext:

   securityContext:
     runAsUser: 1000 # Replace with the UID of your appuser (check with `id -u appuser` in the container)
     runAsNonRoot: true
   

This setup aligns with Azure AKS’s default Pod Security Standards (the restricted profile, which blocks root users by default in newer clusters) and ensures your app has exactly the permissions it needs—no more, no less.

内容的提问来源于stack exchange，提问作者Datz