The Ultimate Guide to High Availability with MariaDB
This is a read-only copy of the MariaDB Knowledgebase generated on 2025-04-22. For the latest, interactive version please visit https://mariadb.com/kb/.

Customer access to docker.mariadb.com

This documentation aims to provide guidance on how to configure access to docker.mariadb.com in your MariaDB Enterprise Operator resources.

Table of contents

Customer credentials

MariaDB Corporation requires customers to authenticate when logging in to the MariaDB Enterprise Docker Registry. A Customer Download Token must be provided as the password. Customer Download Tokens are available through the MariaDB Customer Portal. To retrieve the customer download token for your account:

Then, configure a Kubernetes kubernetes.io/dockerconfigjson Secret to authenticate:

kubectl create secret docker-registry mariadb-enterprise \
   --docker-server=docker.mariadb.com \
   --docker-username=<email> \
   --docker-password=<customer-download-token>

Openshift

If you are running in Openshift, it is recommended to use the global pull secret to configure customer credentials. The global pull secret is automatically used by all Pods in the cluster, without having to specify imagePullSecrets explicitly.

To configure the global pull secret, you can use the following commands:

oc extract secret/pull-secret -n openshift-config --confirm
  • Login in the MariaDB registry providing the customer download token as password:
oc registry login \
  --registry="docker.mariadb.com" \
  --auth-basic="<email>:<customer-download-token>" \
  --to=.dockerconfigjson
  • Update the global pull secret:
oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson

Alternatively, you can also create a dedicated Secret for authenticating:

oc create secret docker-registry mariadb-enterprise \
   --docker-server=docker.mariadb.com \
   --docker-username=<email> \
   --docker-password=<customer-download-token>

MariaDB

In order to configure access to docker.mariadb.com in your MariaDB resources, you can use the imagePullSecrets field to specify your customer credentials:

apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb
spec:
  ...
  image: docker.mariadb.com/enterprise-server:11.4.4-2
  imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: mariadb-enterprise

As a result, the Pods created as part of the reconciliation process will have the imagePullSecrets.

MaxScale

Similarly to MariaDB, you are able to configure access to docker.mariadb.com in your MaxScale resources:

apiVersion: enterprise.mariadb.com/v1alpha1
kind: MaxScale
metadata:
  name: maxscale
spec:
  ...
  image: docker.mariadb.com/maxscale-enterprise:25.01.1
  imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: mariadb-enterprise

Backup, Restore and SqlJob

The batch Job resources will inherit the imagePullSecrets from the referred MariaDB, as they also make use of its image. However, you are also able to provide dedicated imagePullSecrets for these resources:

apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb
spec:
  ...
  image: docker.mariadb.com/enterprise-server:11.4.4-2
  imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: mariadb-enterprise

apiVersion: enterprise.mariadb.com/v1alpha1
kind: Backup
metadata:
  name: backup
spec:
  ...
  mariaDbRef:
    name: mariadb
  imagePullSecrets:
    - name: backup-registry

When the resources from the previous examples are created, a Job with both mariadb-enterprise and backup-registry imagePullSecrets will be reconciled.

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.