How to make etcd 3.4.10 works with random UIDs

[carrodher]

In some environments like openshift, applications are running as a random user ID, overriding what user ID the image itself may specify that it should run as. For an image to support running as an arbitrary user, directories and files that may be written to by processes in the image should be owned by the root group and be read/writable by that group. Files to be executed should also have group execute permissions. Because the container user is always a member of the root group, the container user can read and write these files. The root group does not have any special permissions (unlike the root user) so there are no security concerns with this arrangement. (+info)

I am trying to figure out how to handle random UIDs in container/k8s environments in the new version. According to the changelog, breaking changes in the new version are (#11798):

Changed behavior on existing dir permission.
Previously, the permission was not checked on the existing data directory and the directory used for automatically generating self-signed certificates for TLS connections with clients. Now a check is added to make sure those directories if already exist, has a desired permission of 700 on Linux and 777 on Windows.

In previous versions, we are building a container image setting the proper permissions for the root group, on this way, the image works on openshift. With the new version the following error appears when starting the container:

etcd_1  | 2020-07-20 17:40:44.067311 C | etcdmain: cannot access data directory: directory "/bitnami/etcd/data/","drwxrwxr-x" exist without desired file permission "-rwx------".

The first solution can be modifying the Dockerfile giving the proper permission to the data dir:

WORKDIR /opt/bitnami/etcd
+RUN chmod -R 700 /bitnami/etcd/data
USER 1001

but now a new error appears when running the container:

etcd_1  | 2020-07-20 18:07:28.957831 C | etcdmain: error listing data dir: /bitnami/etcd/data/

This error is expected because the container is non-root (user 1001) but the permission was changed to 700, so the user 1001 is not able to read/write on a dir that belongs to user/group root with 700.

The final solution is change the owner of the data directory with something like

WORKDIR /opt/bitnami/etcd
+RUN chmod -R 700 /bitnami/etcd/data && chown -R 1001 /bitnami/etcd/data
USER 1001

but this solution is not going to work on some environments like openshift, because the owner is hardcoded to 1001, while this kind of environments (as described at the beginning) are going to overwrite this UID by a random one.

[spzala]

@carrodher the approach to handle file is changed #12242 and backported in the latest patch release of 3.4 so I am closing the issue but feel free to reopen if needed. Thanks!