Details
Description
When run with no security context configured for the pod, i.e. not best practice but allowed, the users for each container do not match (which is best practice): server runs as 1000 always, fluent bit runs as 8243 but ultimately should not matter.
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
This means that as https://issues.couchbase.com/browse/MB-46485 was rejected, the logging side car has no access to the logs in the shared volume. The server container does not allow anyone other than the user & group to read the logs.
The use of a fixed UID is explicitly recommended against by Openshift: https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids
On Openshift, there is a custom security context approach which means unless configured differently by the administrator (which is not recommended either) the UIDs have to use a specific range. Without this we could default the security context for the pods but unfortunately that would then break Openshift.
Currently the recommendation would be to run with a security context anyway, and we can cover this use case with documentation. It does mean that people may deploy without a context, see the issue and raise a support request instead of reading the documentation though.
We therefore need to make this section more visible particularly for log forwarding: https://docs.couchbase.com/operator/current/resource/couchbasecluster.html#couchbaseclusters-spec-securitycontext
The other options are:
- Update the server container to allow all to read the logs.
- Update the fluent bit container to use the same UID. This may not work with randomisation on a per-container basis, or if the server container changes - it does not help the current containers either.
Attachments
Issue Links
- relates to
-
K8S-2244 Document Removal of Mutation
- Closed