HCL Commerce container users and privileges

It is a software security best practice to limit and layer access to only those resources that are required to fulfill a strictly defined task. Inheriting additional access to resources or information threatens greater consequences when that access is gained or exploited by an unauthorized party, compared with what may otherwise be a more restricted attack vector or opportunity. This principle extends to running HCL Commerce application containers, and to the various internal utilities and processes that maintain them within your larger e-commerce deployment.

In earlier releases of HCL Commerce, Docker images were run with root privileges by default. Beginning with HCL Commerce 9.1.14.0, provided HCL Commerce application images are supplied with a non-root user and user group. This user is intended to be used to run the containers and their applications within your deployment, more strictly limiting access to host container resources.

The user that is introduced is comuser with UID 1000. Additionally, this user is added to the user group named comuser with GID 1000.

Note: The provided sample IBM Db2 Database image is required to be started as the root user due to IBM Db2 limitations. This image is intended and is limited to use within development and testing environments only.

Restriction: Upgrading Power-based environments to non-root containers is currently not supported. New deployments are supported.

Non-root user update considerations

Overall, non-root containers are more secure as they can prevent any malicious or vulnerable code from gaining privileged permissions on the container host operating system. However, this change can introduce some issues if HCL Commerce has been run as the root user prior upgrading to HCL Commerce 9.1.14.0 or greater, or if you have existing customizations that are not designed for use with the non-root user.

Review the following considerations before upgrading your deployment to non-root user enabled images:

Customization code
Since file permissions are related to users and groups, any customization code manipulating files must be evaluated to ensure that any files being manipulated have the right permissions for the comuser user and group.
For example, if any customization code creates temporary files in the root user home directory, /root/, or any operating system directories owned by the root user, an updated deployment will no longer have access to these files. In this case, your custom code must be updated to create any temporary files within the /tmp/ directory, or have those files created and updated within the comuser home directory, /home/comuser/. Ensure that all file permissions are updated appropriately.
WCB utility
Customization code is normally packaged by the WCB utility for deployment. If the WCB utility is run within the ts-utils container, the file permissions for the customization code also matters, as the ts-utils container is also run as the non-root comuser user. Ensure that the customization code being mounted or copied into the ts-utils container can be accessed by the comuser user and group to prevent any issues.
Custom Docker image build
When a custom Docker image is built on top of an HCL Commerce image, keep in mind that the current user context is comuser, and not root.
This change primarily impacts the RUN instructions in your Dockerfile. For example, if you install additional software package using the system package manager, these commands will fail unless you update the Dockerfile and use the USER instruction to set the user to root first.
Tip: Due to the update from CentOS to UBI in the same release, the yum package manager has been replaced by dnf. If you do install or modify the packages within your custom containers, ensure that you update your Dockerfile to account for this change.
Similar to permission issues when issuing system commands, keep file permissions in mind when using the COPY or ADD commands. For example,
```
COPY --chown=comuser:comuser ./my-custom-script /SETUP/bin/
```
In all of these cases, do not forget to switch the user context back to comuser after your privileged instructions.
Web servers
Since web server-based images are now run by a non-root user, no privileged ports (1024 and below) can be used.
If you have customized the IBM HTTP Server configuration or plug-in to use privileged ports, such as 80 or 443, you must update your configuration file to use a non-privileged port instead.
CI/CD pipeline
If you use a CI/CD pipeline, you must review your tools and scripts to ensure that any files that are added into your custom images are done so with the proper file ownership and permissions based on the provided guidelines.
Utilities
HCL Commerce provides utilities for updating and maintaining your e-commerce site, packaged within the ts-utils container. Some utilities, such as dataload, require additional configuration and data files to run. When these files are copied or mounted into the ts-utils container, ensure that they have the proper file ownership and permissions based on the provided guidelines.
Mounted volumes and external files in Docker deployments
In Docker deployments, a host volume that is mounted into a container run by Docker has its file permissions preserved. Ensure that any mounted directories and any contained files have the correct permissions set in order to be accessed and manipulated within the container. If you are using the provided Docker Compose project for your environment, this consideration is already accounted for.
Assets Tool Persistent Volume Container (PVC)
In Kubernetes deployments, a PVC is used to persist files that are used by the Assets Tool in Management Center for HCL Commerce. The upgrade to a non-root user container presents a potential issue depending on the type of PVC that was initially provisioned:
- A readWriteOnce access mode storage presents no issues during this upgrade.
  Typically PVC storage is provisioned by the cloud storage class as a readWriteOnce access mode PVC, and is mounted with the root user as the owner. The fsGroup is set to 1000 in the HCL Commerce Helm Chart, ensuring that the non-root user will still retain full read and write access to any and all preexisting files and directories in the mounted volume.
- A readWriteMany access mode storage presents a permissions update requirement during this upgrade.
  A readWriteMany type of PVC, which can be provisioned by a different provider, such as NFS Provisioner, presents an obstacle with user permissions during this upgrade. In this case, the fsGroup specified in the HCL Commerce Helm Chart will not have any influence on existing files in the volume. Thus, the file permissions within your PVC must be changed to remain accessible by the non-root user.
  To update your readWriteMany PVC file permissions, see Updating PVC file permissions.