Hello, I'm currently looking to configure my RKE2 cluster (v1.23.6+rke2r2) to be more secure based on CIS 1.6. Is there a best practice or a consensus to be compliant with this CIS test ?

1.1.12 - Ensure that the etcd data directory ownership is set to

etcd:etcd

1. Check that the

etcd

user and group exists on the host. If they don’t, exit with an error.

2. Create etcd’s data directory with

etcd

as the user and group owner.

3. Ensure the etcd process is ran as the

etcd

user and group by setting the etcd static pod’s

SecurityContext

appropriately.

Source: https://rancher.com/docs/rancher/v2.6/en/security/hardening-guides/rke2-1.6-hardening-2.6/#ensure-etcd-is-configured-properly User creation is (partly ?) documented:

sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U

Questions: 1 - Is there a reason to not specify a UID/GID (as opposed to RKE) ? 2 - What is the best way to set the

SecurityContext

for etcd pods ? • Is it done by enabling cis profile into

config.yaml

? (This is not the case of my cluster currently as I try to pass test before enabling it.) • As opposed to RKE, it seems to not be possible to set etcd user/group explicitly into

config.yaml

. • Last option seems to update

/var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml

Let me know if I misunderstood something.

You can specify uid/gid when creating etcd user and group, that's an exercise for the reader. They must both be named

etcd

iirc

that's an exercise for the reader.

ok

...so unless you want to break expectations, I wouldn't advise changing it.

ok, thank you for this. I will continue my investigations regarding point 2.

I think another reason that UID/GID isn't specified is because they don't need to match between master nodes as they'd be writing to local and not shared file systems.

Hello @rapid-helmet-86074 I'm agree with this. But wouldn't it be easier to define it equally over the nodes to set the securitycontext ? For me the answer is "yes". There's no problem currently, it just takes more time to understand/fix this point (the first time).

If you don't know the knowledge level of the user following the instructions, you might either confuse people about needing to check available UID/GID numbers or when someone has one conflicting with what's arbitrarily chosen for the docs. So leaving it off avoids the questions while still suggesting to anyone who cares that the UID/GID numbers don't matter and can be set as what they want.