Chainguard Container for mongodb-kubernetes-operator

Chainguard's MongoDB Kubernetes Operator image enables you to deploy a MongoDB community instance to a Kubernetes cluster, as well as support replica sets, scaling the replicas up or down, version upgrades, custom roles, and TLS security.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/mongodb-kubernetes-operator:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

Chainguard's MongoDB Kubernetes Operator image is comparable to the upstream image. Switching to the Chainguard image should not require any changes to your existing setup. However, the operator expects /bin/sh to be available in the MongoDB container image. If you're not using the -dev variant, you'll need to ensure your MongoDB image includes bash or a bash-binsh symlink to provide compatibility.

We also attempted to secure MongoDBCommunity resource connections using TLS, but encountered SSL handshake failures in the replica set pods when following the guide, both with our image and the upstream image.

Upstream runs the container as uid=2000 and gid=0, but we've verified that the image works correctly with uid=65532 and gid=65532, so we've configured it to run as non-root.

Note that upstream components of the MongoDB Kubernetes Operator use different versioning schemes—for example, the main operator uses versions like 0.12.x, while the version hook component uses 1.0.x. You can see this in the upstream release.json. In contrast, Chainguard images for all related components (e.g., the operator and version hook) will share the same tag, aligned with the main operator version. This is due to our Git-based automation, and because upstream does not provide separate Git tags for components like the version hook (see tags). While this differs from upstream's tagging scheme, all components are still built from the same source and version-aligned internally. Just be aware that users will not see separate tags per component.

Getting Started

To get started with Chainguard's MongoDB Kubernetes Operator image, begin by installing the CRDs:

kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes-operator/refs/heads/master/config/crd/bases/mongodbcommunity.mongodb.com_mongodbcommunity.yaml

To launch the MongoDB Kubernetes Operator in a Docker container, use the following command:

docker run --rm \
    --net=host \
    -v ~/.kube/config:/root/.kube/config:ro \
    -e KUBECONFIG=/root/.kube/config \
    -e AGENT_IMAGE="quay.io/mongodb/mongodb-agent-ubi:108.0.2.8729-1" \
    -e VERSION_UPGRADE_HOOK_IMAGE="quay.io/mongodb/mongodb-kubernetes-operator-version-upgrade-post-start-hook:1.0.9" \
    -e READINESS_PROBE_IMAGE="quay.io/mongodb/mongodb-kubernetes-readinessprobe:1.0.22" \
    -e WATCH_NAMESPACE="*" \
    cgr.dev/ORGANIZATION/mongodb-kubernetes-operator:latest

To deploy the MongoDB Kubernetes Operator in your cluster, create the required service account and role:

cat <<EOF > service_account.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mongodb-kubernetes-operator
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: mongodb-kubernetes-operator
  namespace: default
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["mongodbcommunity.mongodb.com"]
  resources: ["mongodbcommunity", "mongodbcommunity/status", "mongodbcommunity/spec", "mongodbcommunity/finalizers"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: mongodb-kubernetes-operator-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: mongodb-kubernetes-operator
  namespace: default
roleRef:
  kind: Role
  name: mongodb-kubernetes-operator
  apiGroup: rbac.authorization.k8s.io
EOF

Next, create a deployment manifest that will deploy the operator with the Chainguard image:

cat <<EOF > manager.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    email: support@mongodb.com
  labels:
    owner: mongodb
  name: mongodb-kubernetes-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      name: mongodb-kubernetes-operator
  strategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: mongodb-kubernetes-operator
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: name
                operator: In
                values:
                - mongodb-kubernetes-operator
            topologyKey: kubernetes.io/hostname
      containers:
      - command:
        - /usr/local/bin/entrypoint
        env:
        - name: WATCH_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: OPERATOR_NAME
          value: mongodb-kubernetes-operator
        - name: AGENT_IMAGE
          value: quay.io/mongodb/mongodb-agent-ubi:108.0.2.8729-1
        - name: VERSION_UPGRADE_HOOK_IMAGE
          value: quay.io/mongodb/mongodb-kubernetes-operator-version-upgrade-post-start-hook:1.0.9
        - name: READINESS_PROBE_IMAGE
          value: quay.io/mongodb/mongodb-kubernetes-readinessprobe:1.0.22
        - name: MONGODB_IMAGE
          value: mongodb-community-server
        - name: MONGODB_REPO_URL
          value: quay.io/mongodb
        image: cgr.dev/ORGANIZATION/mongodb-kubernetes-operator:latest
        imagePullPolicy: Always
        name: mongodb-kubernetes-operator
        resources:
          limits:
            cpu: 1100m
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 200Mi
        securityContext:
          readOnlyRootFilesystem: true
          runAsUser: 2000
          allowPrivilegeEscalation: false
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      serviceAccountName: mongodb-kubernetes-operator
EOF

Finally, apply the service account and deployment:

kubectl apply -f service_account.yaml
kubectl apply -f manager.yaml

Documentation and Resources

• Deploy and configure MongoDB resources
• Create a database user with SCRAM authentication.
• Secure MongoDB resource connections using TLS

What are Chainguard Containers?

Chainguard Containers are minimal container images that are secure by default.

In many cases, the Chainguard Containers tagged as :latest contain only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager. Chainguard Containers are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a -dev variant.

Although the -dev container image variants have similar security features as their more minimal versions, they feature additional software that is typically not necessary in production environments. We recommend using multi-stage builds to leverage the -dev variants, copying application artifacts into a final minimal container that offers a reduced attack surface that won’t allow package installations or logins.

Learn More

To better understand how to work with Chainguard Containers, please visit Chainguard Academy and Chainguard Courses.

In addition to Containers, Chainguard offers VMs and Libraries. Contact Chainguard to access additional products.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.