For production deployments, it's good security practice to run software event broker containers with a non-zero UID:
- If the container runtime is launched by a root user (that is, in rootful mode), the host user namespace is shared with the software event broker container; therefore having a non-root container user limits the damage that a malicious process could cause if it were to break out of the container and into the host.
- With rootless containers, the host and containers do not share a user namespace. Root users within the container are mapped to non-root users in the host.
Specifying the Container UID
Both Docker and Podman allow you to specify which user a container should run as. In both cases, the UID is set with the --user or -u option in the create or run command.
If you don't specify this argument, the command runs as the user specified in the container image.
The default User ID in a Solace container is 1000001. That is, if you do not specify the -u parameter, the container runs with UID=1000001. In a rootless environment, the container will not run because the OS won't allocate a UID range that starts with 1000001 within the user namespace. To resolve this, specify a -u parameter with a smaller non-zero user ID when you start the container.
Additional Linux Capabilities
When a software event broker container is created, all the processes launched within the container have effective Linux capabilities
If there is an operational need to set a Linux environment limit, and making such adjustments is allowed by the environment, you can specify the --ulimits option when you create the software event broker container. For example, if the environment allows it, we recommend that you permit the software event broker container to mlock() as much memory as it requires. To do this, you specify --ulimit memlock=-1 when you call the docker create or podman create command. For more information about using the --ulimit option, see Setting the Number of Concurrent Open Files for Container Images and Setting the Resource Limit for the Size of Core Files.
Configuring Privileged Ports
A typical Linux operating system (including the container runtime's Linux virtual machine) sets the privileged port range from 0 to 1023 for the root user. If a user has a non-zero UID, the privileged ports will not be available for use. To overcome this issue, you can set port numbers using configuration keys.
For a list of configuration keys you can use to set the port numbers of various services, refer to Initializing a Software Event Broker Container.
Volume Ownership and Permissions
The software event broker container user must have read and write access to all the files and directories in its associated volumes. The mechanism for doing this is different for rootful versus rootless containers:
- Rootful containers share the user namespace with the host, so you can simply run
chownorchmodto apply the required permissions. - Rootless containers have a separate user namespace, so you can use
podman unshareto runchownorchmodwithin the container's user namespace to update the permissions. For details, see Rootless Containers and Managing Storage for Container Images.
You can use the following chown command (with unshare if you're using rootless Podman) on the Linux host to change the owner and group of the software event broker container's volume to the desired<UID>:<GID>
chown --recursive <container uid>:<container gid> <host path of volume>
To ensure that the volumes have read and write access privileges for the software event broker container user, execute the following chmod (with unshare if you're using rootless Podman) command on the Linux host.
chmod --recursive u+rwx,g-rwx,o-rwx
The default umask for the container is 0077, so the software event broker container has read and write access to all the new files.
If an external tool needs read access to files in one of the volumes, you can use the chmod command on the Linux host and specify a umask of 0022 when creating the container.
chmod --recursive u+rwX,g+rX,o+rX