Details
Description
Having this hard coded as 1000 is just far too dangerous. For a start a lot of images out there assume a UID of 1000 ("couchbase" default). Problem is, if you forget to add the pod security context to something and also run as a different user, things will break.
Attachments
Issue Links
- relates to
-
K8S-2512 [Backup] PermissionError: [Errno 13] Permission denied while trying to setup restore logging.
-
- Closed
-
Gerrit Reviews
| For Gerrit Dashboard: K8S-2517 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 174265,1 | K8S-2517: runAsUser Test Randomization | 2.3.x | couchbase-operator | Status: NEW | 0 | +1 |
Activity
Don't think this is valid since Couchbase only recognizes non-root user of 1000. Otherwise you'd have to use uid=0. Anything else fails. This section of docs is to highlight fsGroup that user should belong to for Persistent Volumes.
Regarding backup, apparently this process can run as different. Perhaps then backup should have its own security context.
Per constraints, new definition of done is that we use this only for backup and not for Couchbase server pod. Also, note we cannot do this with fluentbit, as the sidecar needs to be able to share the volume mount.
Simon Murray I've tried simply picking a random number where we apply the security context, but CB server pods immediately fail with:
whoami: cannot find name for user ID 6481
The docs suggest that if we are running as non-root, we must set runAsUser to 1000; does that not conflict with this change?