Description:
The MySQL Operator currently utilizes initContainers that run as root to prepare directory permissions for its various operations. This is also referenced in https://bugs.mysql.com/bug.php?id=115836
This pattern has been observed for:
The fixdatadir initContainer, which executes chown 27:27 /var/lib/mysql && chmod 0700 /var/lib/mysql.
YAML
# Relevant snippet for fixdatadir
- name: fixdatadir
image: {spec.operator_image} # or similar
command: ["bash", "-c", "chown 27:27 /var/lib/mysql && chmod 0700 /var/lib/mysql"]
securityContext:
runAsNonRoot: false
runAsUser: 0
# ... other capabilities
volumeMounts:
- name: datadir
mountPath: /var/lib/mysql
The fixdumpdir initContainer (observed in backup job specifications), which executes chown 27:27 /mnt/storage && chmod 0700 /mnt/storage.
YAML
# Relevant snippet for fixdumpdir
initContainers:
- name: fixdumpdir
image: {backup_job_container_spec['image']}
command: ["bash", "-c", "chown 27:27 /mnt/storage && chmod 0700 /mnt/storage"]
securityContext:
runAsUser: 0
volumeMounts:
- name: tmp-storage
mountPath: /mnt/storage
Both these initContainers currently require runAsUser: 0 (root privileges) to perform chown and chmod. While specific capabilities like CHOWN and FOWNER are added and others are dropped, running any container as root increases the potential attack surface. More importantly, this practice can be incompatible with stricter Kubernetes security contexts, such as those enforcing Pod Security Standards (PSS) like "Baseline" or "Restricted," which may disallow running containers as root or requiring specific non-root UIDs. This forces users to either run less secure clusters or create exceptions for the MySQL Operator.
This feature request is to refactor the operator's approach to managing these directory permissions to eliminate the need for root-running initContainers. The goal is to allow all operator-managed pods (including their initContainers) to run with runAsNonRoot: true and as a defined non-root user.
References:
fixdatadir context: https://github.com/mysql/mysql-operator/blob/cceac9e5cf006c2b7f501fe95cad72168191ec30/mysq...
storage_api.py (related to fixdumpdir): https://github.com/mysql/mysql-operator/blob/trunk/mysqloperator/controller/storage_api.py...
How to repeat:
How to repeat *:
Deploy the MySQL Operator in a Kubernetes cluster.
Create a MySQL InnoDB Cluster instance.
Inspect the Pod specification for the MySQL server instances. Observe the fixdatadir initContainer and its securityContext (runAsUser: 0).
Trigger a backup operation (if this functionality is configured/used).
Inspect the Pod specification for the backup job. Observe the fixdumpdir initContainer and its securityContext (runAsUser: 0).
Attempting to run these pods in a Kubernetes namespace with a "Restricted" Pod Security Standard applied will likely result in the pods being denied or requiring modifications to the security policy.
Suggested fix:
Suggested fix:
The primary suggested approach is to leverage Kubernetes' built-in mechanisms for volume permission management, primarily securityContext.fsGroup:
Utilize PodSecurityContext.fsGroup:
For Pods requiring access to volumes like /var/lib/mysql or /mnt/storage, set spec.securityContext.fsGroup to 27 (or the GID corresponding to the mysql user). This instructs the Kubelet to:
Ensure the mounted volume is owned by the specified fsGroup (GID 27).
Make the volume writable by this GID. The Kubelet performs this action before any containers (including initContainers) are started.
Main Container Handles chmod:
Once fsGroup has set the correct group ownership and writability, the main container (MySQL server or backup utility), which should also be configured to run as UID 27 / GID 27 (runAsUser: 27, runAsGroup: 27), can then perform the chmod 0700 on its required directories as part of its entrypoint script. The user 27 would be the owner (or at least have group write access) and thus permitted to change modes on files/directories it owns or has group permissions for.
Remove Privileged InitContainers:
With fsGroup and the main container handling permissions, the fixdatadir and fixdumpdir initContainers, in their current root-running form, would become redundant and can be removed or significantly altered to not require root.
Benefits:
Enhanced Security: Adheres to the principle of least privilege by avoiding root containers.
Improved Compatibility: Allows the MySQL Operator to run seamlessly in environments with strict Pod Security Standards (e.g., PSS Restricted) without requiring exceptions.
Simplified Operations: Reduces the need for users to manage custom security policies specifically for the operator.
This change would align the MySQL Operator with modern Kubernetes security best practices and make it more secure and easier to operate in a wider range of environments.
