-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kubernetes operator not setting folder permissions before de-escalating permissions #1363
Comments
It sounds like you understand the issue well. A pull request to fix it would be very welcome. Thanks. |
Did some more digging, the Helm recipe has a specific init container to fix this that can be enabled on demand, and with that the pods start up as expected, and work. Tried to work on getting that option added, but I can't even get the code to build and pass tests without my modifications so gave up after like 2 hours... |
This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring. |
Removing the stale label as this issue is legitimate. I recall some work around this last year or so, we'll have to dig up a bit the history to understand what changed and our motivation around the change. |
I'm running into this issue running cluster-operator v2.6.0 on an eks cluster version 1.28. I followed the docs and got this error: |
What resolved this for me was in the docs for Using Openshift
|
RE @jonathandavis805 That worked for me as well, but works because it removes some of statefulSet security settings :( |
If you have this problem, please investigate what changes are necessary and share here. You can pause reconciliation and make modifications to the STS for example. |
I have this same problem. Does anyone have a solution? With @jonathandavis805 's it won't even try to start up, as it gets stuck at
|
You can work around this issue by adding an override to your RabbitmqCluster object: apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
...
spec:
...
override:
statefulSet:
spec:
template:
spec:
containers: []
initContainers:
- command:
- sh
- '-c'
- >-
chown -R 999:999 /var/lib/rabbitmq/mnesia;
chmod g+ws /var/lib/rabbitmq/mnesia
image: alpine:latest
imagePullPolicy: IfNotPresent
name: setup-fix-permissions
securityContext:
runAsUser: 0
volumeMounts:
- mountPath: /var/lib/rabbitmq/mnesia/
name: persistence Change the uid and gid for the The operator will not accept overrides for |
Describe the bug
This is similar to #1327 but with CephFS PVCs. Also at https://stackoverflow.com/questions/67771239/rabbitmq-fails-to-start-with-persistence-storage-on-kubernetes-permission-denie
The pod starts up but has no write access to the mnesia folder
I've deployed the standard example operator and test cluster from: https://rabbitmq.com/kubernetes/operator/quickstart-operator.html
The only modification I've added to the test cluster is that I set the storage-class.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
At step 3. the process fails as the binary does not have write access to the persistence changes
The volume that gets created is owned by root by default as with all other PVCs:
If I change the folder ownership tot UID/GID 999:999 aka rabbitmq:rabbitmq then the pod starts up and works fine.
The statefulset is missing the command to claim the folder as part of init before handing over to the non-privileged user to start the process... Unfortunately this needs to be fixed in the operator as every pod has the same issue when new PVCs are created, as it'll overwrite any changes to the configs, rightfully so.
Version and environment information
The text was updated successfully, but these errors were encountered: