fix: make Docker images backward compatible with runAsUser: 1000

[buger]

Summary

• Remove --chown=65532:65532 from COPY in ci/Dockerfile.distroless so non-FIPS images work with any UID (e.g. runAsUser: 1000)
• Add chmod -R a+rX after dpkg install so files are world-readable regardless of container uid
• FIPS/DHI builds pass NONROOT_CHOWN=true build arg to preserve explicit nonroot ownership

Test plan

• Service starts with runAsUser: 1000
• Service starts with runAsUser: 65532
• FIPS image still has correct 65532:65532 ownership

🤖 Generated with Claude Code

[probelabs]

This PR updates the Docker build process to enhance backward compatibility with Kubernetes environments that use runAsUser. The changes remove the hardcoded chown from the final image stage, making the container compatible with arbitrary user IDs. To maintain security for FIPS builds, a conditional chown is added, controlled by a new NONROOT_CHOWN build argument, which is enabled in the release workflow for FIPS images.

Files Changed Analysis

• .github/workflows/release.yml: Adds the NONROOT_CHOWN=true build argument to the FIPS image build steps, ensuring that these specific images retain their explicit user and group ownership.
• ci/Dockerfile.distroless:
  • Removes the --chown=65532:65532 flag from the COPY instruction in the final stage. This allows the container to run with any user ID.
  • Adds a chmod -R a+rX /opt/tyk-pump/ command to make the application directory world-readable and executable.
  • Introduces a conditional chown command that runs only when NONROOT_CHOWN is set to true, preserving the original behavior for FIPS builds.

Architecture & Impact Assessment

• Accomplishment: The PR resolves an issue where the Docker image would fail to start in environments with strict security contexts (e.g., Kubernetes with runAsUser: 1000), by making file permissions more flexible for non-FIPS images.
• Key Technical Changes: The core change is the shift from a hardcoded file ownership in the Dockerfile to a more flexible permission model using chmod and a conditional chown controlled by a build argument.
• Affected Components: The primary impact is on the container build and release process and the runtime behavior of the resulting Docker images, particularly in secured container orchestration platforms.

Build Logic Flow

graph TD
    subgraph "Docker Build (ci/Dockerfile.distroless)"
        A[Start Build] --> B[Install .deb package];
        B --> C[Make files world-readable];
        C --> D{NONROOT_CHOWN == true?};
        D -- Yes --> E[chown to non-root user];
        D -- No --> F[Skip chown];
        E --> G[Copy files to final image];
        F --> G;
    end

    subgraph "CI/CD (.github/workflows/release.yml)"
        H[Release Workflow] --> I{Is it a FIPS build?};
        I -- Yes --> J[Build with NONROOT_CHOWN=true];
        I -- No --> K[Build with default NONROOT_CHOWN=false];
    end

    J --> A;
    K --> A;

Loading

Scope Discovery & Context Expansion

The changes are confined to the Docker packaging and CI/CD pipeline, directly affecting how the tyk-pump application is deployed and managed in containerized environments. This modification enhances compatibility with platforms like OpenShift and other Kubernetes distributions that enforce non-root user execution policies. The application code itself is unaffected. The changes correctly isolate the stricter ownership requirements to the FIPS-compliant images while providing a more flexible default for standard images.

Metadata

• Review Effort: 2 / 5
• Primary Label: bug

---

Powered by Visor from Probelabs

Last updated: 2026-04-20T16:51:54.924Z | Triggered by: pr_opened | Commit: 275d9f6

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:14	The command `chmod -R a+rX /opt/tyk-pump/` makes application files and directories world-readable. While this change is intended to support running the container with arbitrary non-root user IDs, it weakens file system permissions and deviates from the principle of least privilege. If any sensitive information is packaged within the `/opt/tyk-pump/` directory, it could be exposed to any other process or user within the container. 💡 Suggestion Verify that no sensitive files, such as private keys, certificates, or configuration files with default secrets, are included in the `/opt/tyk-pump/` directory within the built image. For a more secure alternative, consider using group-based permissions. This would involve creating a dedicated group, changing the directory's group ownership, granting read/execute permissions to that group (`chmod -R g+rX,o-rwx`), and ensuring the container runs with a user that is part of this group (e.g., via `runAsGroup` or `supplementalGroups` in Kubernetes).

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

Security Issues (1)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:14	The command `chmod -R a+rX /opt/tyk-pump/` makes application files and directories world-readable. While this change is intended to support running the container with arbitrary non-root user IDs, it weakens file system permissions and deviates from the principle of least privilege. If any sensitive information is packaged within the `/opt/tyk-pump/` directory, it could be exposed to any other process or user within the container. 💡 Suggestion Verify that no sensitive files, such as private keys, certificates, or configuration files with default secrets, are included in the `/opt/tyk-pump/` directory within the built image. For a more secure alternative, consider using group-based permissions. This would involve creating a dedicated group, changing the directory's group ownership, granting read/execute permissions to that group (`chmod -R g+rX,o-rwx`), and ensuring the container runs with a user that is part of this group (e.g., via `runAsGroup` or `supplementalGroups` in Kubernetes).

\n\n ### ✅ Architecture Check Passed

No architecture issues found – changes LGTM.

\n\n

✅ Performance Check Passed

No performance issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-04-20T16:51:13.326Z | Triggered by: pr_opened | Commit: 275d9f6

💡 TIP: You can chat with Visor using /visor ask <your question>

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE