Fix issue causing clustermesh-apiserver/kvstoremesh to not start when run with a non-root user #31539
Conversation
giorio94
added
kind/bug
|
/test |
|
What about switching the base image from scratch to distroless nonroot? That's what we've done for Hubble Relay and it also solves this GOPS problem without resorting to chmoding. |
Sounds reasonable to me, and it would also be consistent with Hubble Relay. The only caveat is that it wouldn't work if a user (or mutating webhook) configured a user ID different from |
|
/cc @rolinh ^^ |
|
From what I remember, it's not causing issues. Well, if it is, we'll have to fix Hubble Relay as well anyways 🙂
This is correct. I believe it can be overwritten via the securityContext however. |
Fair enough. I'll update this PR to mimic the Hubble Relay approach then, to ensure consistency from that point of view. |
giorio94
force-pushed
the
mio/clustermesh-non-root-user
branch
2 times, most recently
from
fb51c4f
to
fa426d1
Compare
giorio94
changed the title
|
Updated, back to reviewable state. Concerning the backport to v1.15, I'm planning on preparing a slightly reduced version of the first commit using |
giorio94
added
the
backport/author
|
/test |
gops needs to write data (e.g., the PID file) to the file-system, which turned out to be tricky when using scratch as base image, in case the container is then run using a non-root UID. Let's use the most basic version of a distroless image instead, which contains: - ca-certificates - A /etc/passwd entry for a root, nonroot and nobody users - A /tmp directory - tzdata This aligns the clustermesh-apiserver image with the Hubble Relay one, and removes the need for manually importing the CA certificates. The GOPS_CONFIG_DIR is explicitly configured to use a temporary directory, to prevent permission issues depending on the UID configured to run the entrypoint. Finally, we explicitly configure the fsGroup as part of the podSecurityContext, to ensure that mounted files are accessible by the non-root user as well. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Configure the specified clustermesh-apiserver etcd container security context for the etcd-init container as well, to make sure that they always match, and prevent issues caused by the init container creating files that cannot be read/written by the main instance later on. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
giorio94
force-pushed
the
mio/clustermesh-non-root-user
branch
from
fa426d1
to
0a82f93
Compare
|
Rebased to fix conflict. |
|
/test |
|
@squeed Gentle ping 🙏 |
giorio94
added
backport-pending/1.15
giorio94
removed
the
backport/author
github-actions
bot
added
backport-done/1.15
gops needs to write data (e.g., the PID file) to the file-system, which turned out to be tricky when using scratch as base image, in case the container is then run using a non-root UID.
Let's use the most basic version of a distroless image instead, which contains:
This aligns the clustermesh-apiserver image with the Hubble Relay one, and removes the need for manually importing the CA certificates. The GOPS_CONFIG_DIR is explicitly configured to use a temporary directory, to prevent permission issues depending on the UID configured to run the entrypoint.
We explicitly configure the fsGroup as part of the podSecurityContext, to ensure that mounted files are accessible by the non-root user as well.
Finally, configure the specified clustermesh-apiserver etcd container security context for the etcd-init container as well, to make sure that they always match, and prevent issues caused by the init container creating files that cannot be read/written by the main instance later on.
Should fix #31524