[TT-17009] make Docker images backward compatible with runAsUser: 1000

[buger]

Summary

• Remove --chown=65532:65532 from non-FIPS Dockerfile builds to restore backward compatibility with helm charts using runAsUser: 1000
• Files are made world-readable via chmod -R a+rX
• FIPS/DHI builds still get proper 65532 ownership via NONROOT_CHOWN build arg

Test plan

• Gateway starts with runAsUser: 1000 (old helm default)
• Gateway starts with runAsUser: 65532
• FIPS image still has proper nonroot ownership

🤖 Generated with Claude Code

[github-actions]

API Changes

no api changes detected

[probelabs]

This PR fixes a backward compatibility issue in the Docker images, allowing them to run with user IDs other than the default 65532, such as runAsUser: 1000 which is common in Helm chart deployments.

The change removes the hardcoded --chown=65532:65532 from the COPY instruction in the Dockerfile. Instead, it makes the application files world-readable and executable (chmod -R a+rX) during the build. This ensures that the container can be started with different user IDs.

To maintain stricter security for FIPS builds, a new build argument NONROOT_CHOWN is introduced. When set to true, it explicitly runs chown -R 65532:65532 on the application directory. The .github/workflows/release.yml file has been updated to pass NONROOT_CHOWN=true during FIPS image builds, ensuring they retain the specific user ownership.

Files Changed Analysis

• ci/Dockerfile.distroless: The core change is here. The COPY instruction was modified to remove the --chown flag. A multi-step RUN command was added to make files world-readable and to conditionally change file ownership based on the new NONROOT_CHOWN build argument.
• .github/workflows/release.yml: This CI pipeline file was updated to set NONROOT_CHOWN=true in the build-args for the two FIPS image build jobs, activating the stricter ownership for those specific images.

Architecture & Impact Assessment

• What this PR accomplishes: It restores the ability for users to run the Tyk Gateway Docker container with an arbitrary user ID (e.g., 1000), fixing a regression that broke compatibility with existing Kubernetes and Helm configurations.

• Key technical changes introduced:

  1. Replaced a hardcoded file ownership change (COPY --chown) with a more flexible file permission setting (chmod a+rX).
  2. Introduced a conditional build argument (NONROOT_CHOWN) to apply strict ownership only when needed (for FIPS images).
  3. Updated the release workflow to utilize this new build argument for FIPS builds.

• Affected system components: The Docker image build process and the runtime security context of the resulting containers. This directly impacts end-users deploying the gateway via Docker, especially in Kubernetes environments.

• Build Logic Flow:

graph TD
A[Start Docker Build] --> B{NONROOT_CHOWN == true?};
B --|Yes (FIPS Build)|--> C[RUN chown -R 65532:65532 /opt/tyk-gateway];
B --|No (Standard Build)|--> D[Permissions set by chmod a+rX only];
C --> E[Final FIPS Image];
D --> F[Final Standard Image];

## Scope Discovery & Context Expansion
This change is localized to the Docker build configuration but has a broad impact on deployment flexibility. The explicit mention of `runAsUser: 1000` and "helm charts" indicates this fix is crucial for users deploying Tyk on Kubernetes, as it's common practice to run containers as a non-root user with a specific ID for security reasons. The previous hardcoded ownership to `65532` forced all users to adopt this specific user ID, breaking existing setups. This PR creates two distinct permission models: a flexible one for standard images and a hardened one for FIPS-compliant images, addressing both usability and security requirements.


<details>
  <summary>Metadata</summary>

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


</details>
<!-- visor:section-end id="overview" -->

<!-- visor:thread-end key="TykTechnologies/tyk#8104@d383920" -->

---

*Powered by [Visor](https://probelabs.com/visor) from [Probelabs](https://probelabs.com)*

*Last updated: 2026-04-20T16:53:22.915Z | Triggered by: pr_opened | Commit: d383920*

💡 **TIP:** You can chat with Visor using `/visor ask <your question>`
<!-- /visor-comment-id:visor-thread-overview-TykTechnologies/tyk#8104 -->

[probelabs]

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:16	The UID/GID `65532` is hardcoded in the `chown` command. While this is the standard 'nonroot' user in distroless images, it's better practice to define it as a build argument for clarity and maintainability, especially since it was also used in the now-removed `COPY --chown` instruction. 💡 Suggestion Define an `ARG` for the non-root UID near the top of the Dockerfile and use this variable in the `chown` command. This makes the value explicit and easier to change if needed in the future.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:14-15	The `chmod -R a+rX` command is executed for all builds, including FIPS builds where a `chown -R` is also performed. If the container for a FIPS build is run as user `65532`, which now owns the files, the global read/execute permissions from `chmod` are likely redundant. This results in an unnecessary recursive filesystem traversal during the image build, slowing down the build process for FIPS images. 💡 Suggestion Restructure the logic to only apply the necessary permissions for each case. For FIPS builds (`NONROOT_CHOWN=true`), the `chown` command should be sufficient. For non-FIPS builds, the `chmod` is needed for compatibility. This avoids running two recursive filesystem operations when one is sufficient. 🔧 Suggested Fix RUN dpkg -i /${BUILD_PACKAGE_NAME}_*${TARGETARCH}.deb && rm /*.deb \ && if [ "$NONROOT_CHOWN" = "true" ]; then chown -R 65532:65532 /opt/tyk-gateway/; else chmod -R a+rX /opt/tyk-gateway/; fi

✅ Quality Check Passed

No quality issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-04-20T16:53:08.309Z | Triggered by: pr_opened | Commit: d383920

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

[github-actions]

🚨 Jira Linter Failed

Commit: d383920
Failed at: 2026-04-20 21:03:25 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate branch and PR title rules: branch name 'fix/dockerfile-chown-compat-release-5.12.1' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.