[TT-16950] fix: 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.

Test plan

• Service starts with runAsUser: 1000
• Service starts with runAsUser: 65532

🤖 Generated with Claude Code

[probelabs]

This pull request adjusts the Docker build process to restore backward compatibility for users running the container with a specific user ID (e.g., runAsUser: 1000 in Kubernetes). The change removes a hardcoded file ownership setting that was previously forcing files to be owned by user 65532, which caused permission issues in some environments.

To maintain stricter security for FIPS-compliant images, a new build argument NONROOT_CHOWN has been introduced. This argument is enabled specifically for FIPS builds, ensuring that file ownership is explicitly set to 65532:65532 only when required. For standard builds, the file ownership is no longer changed, and permissions are set to be readable and executable by any user, resolving the compatibility issue.

Files Changed Analysis

• ci/Dockerfile.distroless: The --chown flag was removed from the final COPY instruction. A conditional chown command, controlled by the new NONROOT_CHOWN build argument, was added to the builder stage. Additionally, chmod -R a+rX is now used to ensure the application directory has appropriate read/execute permissions for any user.
• .github/workflows/release.yml: The release workflow was updated to pass NONROOT_CHOWN=true as a build argument when creating the FIPS-enabled Docker images, thereby preserving the previous ownership settings for that specific variant.

Architecture & Impact Assessment

• What this PR accomplishes: It fixes a runtime permission error for non-FIPS Docker images when deployed with a runAsUser security context other than 65532. It restores the previous, more flexible permission model for standard images while retaining stricter ownership for FIPS images.

• Key technical changes introduced:

  • Replaced the static --chown flag in the COPY command with a build-time argument (ARG NONROOT_CHOWN) and a conditional RUN chown command.
  • Modified the GitHub Actions release workflow to set this argument for FIPS builds.

• Affected system components: This change affects the Docker image build process and the runtime behavior of the resulting tyk-pump container, particularly in orchestrated environments like Kubernetes that define a securityContext.

Build Logic Flow

graph TD
    subgraph Docker Build Process
        A[Start Build] --> B{Is it a FIPS build?};
        B -- Yes --> C[Set NONROOT_CHOWN=true];
        B -- No --> D[Use default NONROOT_CHOWN=false];
        C --> E[Builder Stage: RUN ... && chown];
        D --> E;
        E -- COPY --> F[Final Image];
    end
    subgraph Image Runtime
        F --> G{Image Type?};
        G -- FIPS --> H[Files owned by 65532:65532];
        G -- Standard --> I[Files owned by root, readable by all];
    end

Loading

Scope Discovery & Context Expansion

This change is scoped to the Docker packaging of the tyk-pump application. Its impact is primarily felt by users deploying the container image with custom user IDs, a common practice in environments using Pod Security Policies or Standards. The modification to the release workflow indicates a clear separation of concerns between standard and FIPS-compliant builds.

Further investigation could involve reviewing the associated Tyk Pump Helm chart to confirm how runAsUser is configured by default and examining the Git history to understand the context of the original commit that introduced the hardcoded --chown flag, which was likely added for security hardening but had unintended side effects.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-04-20T16:57:28.783Z | Triggered by: pr_opened | Commit: 4fc6669

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

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:14-15	The change introduces world-readable and executable permissions (`a+rX`) on the `/opt/tyk-pump/` directory to support running the container with different user IDs. This is a common pattern for compatibility but weakens defense-in-depth by making all application files accessible to any user or process within the container. If a vulnerability allows an attacker to gain low-privilege code execution, they could read potentially sensitive application files. 💡 Suggestion Please review the contents of the Debian package installed into the image and confirm that no sensitive files (e.g., private keys, configurations with default secrets, proprietary binaries) are located in `/opt/tyk-pump/`. If sensitive files are present, they should be removed from the image or have their permissions restricted.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Security Issues (1)

Severity	Location	Issue
🟡 Warning	ci/Dockerfile.distroless:14-15	The change introduces world-readable and executable permissions (`a+rX`) on the `/opt/tyk-pump/` directory to support running the container with different user IDs. This is a common pattern for compatibility but weakens defense-in-depth by making all application files accessible to any user or process within the container. If a vulnerability allows an attacker to gain low-privilege code execution, they could read potentially sensitive application files. 💡 Suggestion Please review the contents of the Debian package installed into the image and confirm that no sensitive files (e.g., private keys, configurations with default secrets, proprietary binaries) are located in `/opt/tyk-pump/`. If sensitive files are present, they should be removed from the image or have their permissions restricted.

\n\n \n\n

✅ Performance Check Passed

No performance issues found – changes LGTM.

\n\n

✅ Quality Check Passed

No quality issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-04-20T16:57:15.698Z | Triggered by: pr_opened | Commit: 4fc6669

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

[github-actions]

🚨 Jira Linter Failed

Commit: 4fc6669
Failed at: 2026-04-21 10:10:13 UTC

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

🔍 Click to view error details

failed to get Jira issue: failed to fetch Jira issue TT-16950: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

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.