VladPolskiy/mariadb-operator
1
0
Fork 0
mirror of https://github.com/mariadb-operator/mariadb-operator.git synced 2025-08-15 21:02:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update documentation related to securityContext

Browse Source
This commit is contained in:
Martin Montes
2024-05-14 21:36:18 +02:00
parent 36d2e46e5a
commit d994fa2f46
2 changed files with 22 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/GALERA.md
View File

@ -330,25 +330,29 @@ Once you are done with these steps, you will have the context required to jump a
#### Permission denied writing Galera configuration
This error occurs when the user that runs the container does not have enough privileges to write in `/etc/mysql/mariadb.conf.d`:
```bash
Error writing Galera config: open /etc/mysql/mariadb.conf.d/0-galera.cnf: permission denied
```
This error is returned by the `init` container when it is unable to write the configuration file in the filesystem backed by the PVC. In particular, this has been raised by users using longhorn and rook as a storage provider, which in some cases require a specific user to write in the filesystem:
- https://github.com/longhorn/longhorn/issues/3549
The remediation is matching the user expected by the storage provider to be able to write in the PVC:
To mitigate this, by default, the operator sets the following `securityContext` in the `MariaDB`'s `StatefulSet` :
```yaml
apiVersion: k8s.mariadb.com/v1alpha1
kind: MariaDB
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mariadb-galera
spec:
podSecurityContext:
runAsUser: 0
...
securityContext:
fsGroup: 999
runAsGroup: 999
runAsNonRoot: true
runAsUser: 999
```
This enables the `CSIDriver` and the kubelet to recursively set the ownership ofr the `/etc/mysql/mariadb.conf.d` folder to the group `999`, which is the one expected by MariaDB. It is important to note that not all the `CSIDrivers` implementations support this feature, see the [CSIDriver documentation](https://kubernetes-csi.github.io/docs/support-fsgroup.html) for further information.
#### Unauthorized error disabling bootstrap
```bash

40
docs/MAXSCALE.md
View File

@ -685,48 +685,28 @@ helm upgrade --install mariadb-operator mariadb-operator/mariadb-operator --set
#### Permission denied writing `/var/lib/maxscale`
This error occurs when the container does not have enough privileges for writing in `/var/lib/maxscale`:
This error occurs when the user that runs the container does not have enough privileges to write in `/var/lib/maxscale`:
```bash
Failed to create directory '/var/lib/maxscale/maxscale.cnf.d': 13, Permission denied
```
To mitigate this, the following defaults are set by the operator:
To mitigate this, by default, the operator sets the following `securityContext` in the `MaxScale`'s `StatefulSet`:
```yaml
apiVersion: k8s.mariadb.com/v1alpha1
kind: MaxScale
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: maxscale-galera
spec:
...
podSecurityContext:
fsGroup: 996
securityContext:
fsGroup: 996
runAsGroup: 996
runAsNonRoot: true
runAsUser: 998
```
This enables the `CSIDriver` and the kubelet to recursively set the ownership ofr the `/var/lib/maxscale` folder to the group `996`, which is the one expected by MaxScale. It is important to note that not all the `CSIDrivers` implementations support this feature, see the [CSIDriver documentation](https://kubernetes-csi.github.io/docs/support-fsgroup.html) and refer to this [comment](https://github.com/mariadb-operator/mariadb-operator/issues/381#issuecomment-1974828673) for further information.
As an alternative, you can setup an initContainer to perform a `chown`:
```yaml
apiVersion: k8s.mariadb.com/v1alpha1
kind: MaxScale
metadata:
name: maxscale-galera
spec:
...
initContainers:
- name: volume-hack
image: busybox
command:
- /bin/sh
- -c
- chown -R 998:996 /var/lib/maxscale
resources: {}
volumeMounts:
- name: storage
mountPath: /var/lib/maxscale
```
This enables the `CSIDriver` and the kubelet to recursively set the ownership ofr the `/var/lib/maxscale` folder to the group `996`, which is the one expected by MaxScale. It is important to note that not all the `CSIDrivers` implementations support this feature, see the [CSIDriver documentation](https://kubernetes-csi.github.io/docs/support-fsgroup.html) for further information.
## Reference
- [API reference](./API_REFERENCE.md)