Chainguard Container for mongodb-kubernetes-operator-fips

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-fips: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 MongoDB Kubernetes Operator image maintained by MongoDB.

Chainguard's MongoDB Kubernetes 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.

For TLS to work with our FIPS image, we had to add a patch to swap MD5 with SHA-256, since using MD5 caused a crash due to OpenSSL rejecting unsupported algorithms under FIPS mode (EVP_DigestInit_ex failure from md5Hex in SCRAM credential generation).

Note that the upstream image 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.

Additionally, the 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. 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-fips: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-fips: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

Secure MongoDB resource connections using TLS

Add the cert-manager repository to your helm repository list and ensure it's up to date:

helm repo add jetstack https://charts.jetstack.io
helm repo update

Install cert-manager:

helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set crds.enabled=true

Create a TLS-secured MongoDBCommunity resource:

helm repo add mongodb https://mongodb.github.io/helm-charts

helm upgrade --install mongodb-kubernetes-operator mongodb/community-operator \
  --set operator.operatorImageName="ORGANIZATION/mongodb-kubernetes-operator-fips" \
  --set operator.version="latest" \
  --set registry.operator="cgr.dev" \
  --set community-operator-crds.enabled=true

Install mkcert and generate a certificat authority:

brew install mkcert # for Mac
#for Linux / Windows systems refer to https://github.com/FiloSottile/mkcert
mkcert -install

Run the following command and note the location of the generated root CA key and cert:

mkcert --CAROOT

Use the files that you found in the previous step. For example if the location is /root/.local/share/mkcert:

kubectl create configmap ca-config-map --from-file=ca.crt=/root/.local/share/mkcert/rootCA.pem

kubectl create secret tls ca-key-pair  --cert=/root/.local/share/mkcert/rootCA.pem  --key=/root/.local/share/mkcert/rootCA-key.pem

Create the Cert Manager issuer and secret:

cat <<EOF > cert-manager-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
spec:
  ca:
    secretName: ca-key-pair
EOF

cat <<EOF > cert-manager-certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: cert-manager-certificate
  namespace: default
spec:
  secretName: mongodb-tls
  issuerRef:
    name: ca-issuer
    kind: Issuer
  commonName: "*.mongodb-replica-set-svc.default.svc.cluster.local"
  dnsNames:
  - "*.mongodb-replica-set-svc.default.svc.cluster.local"
  - localhost
  ipAddresses:
  - 127.0.0.1
  - 0.0.0.0
EOF

kubectl apply -f cert-manager-issuer.yaml
kubectl apply -f cert-manager-certificate.yaml

Deploy MongoDB:

cat <<EOF > mongo.yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-user-password
type: Opaque
stringData:
  password: "ThisIsA$uperStr0ngPassw0rd!123"

---
apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: mongodb-replica-set
spec:
  type: ReplicaSet
  members: 3
  version: "6.0.5"
  security:
    tls:
      enabled: true
      certificateKeySecretRef: 
        name: mongodb-tls
      caConfigMapRef: 
        name: ca-config-map
    authentication:
      modes: ["SCRAM-SHA-256"]
  users:
    - name: my-user
      db: admin
      passwordSecretRef:
        name: my-user-password
      scramCredentialsSecretName: my-scram
      roles:
        - { name: clusterAdmin,           db: admin }
        - { name: userAdminAnyDatabase,   db: admin }
        - { name: readWriteAnyDatabase,   db: admin }
        - { name: dbAdminAnyDatabase,     db: admin }
  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongodb-agent
              env:
                - name: GODEBUG
                  value: "fips140=off"
EOF

kubectl apply -f mongo.yaml

Wait for the replicaset to be available. Once kubectl wait mongodbcommunity/mongodb-replica-set --for=jsonpath='{.status.phase}'=Running becomes available, you can get your connection string, username, and password by running the following:

kubectl get secret mongodb-replica-set-admin-my-user -o json | jq -r '.data | with_entries(.value |= @base64d)' > conn.json

USERNAME=$(jq -r '.username' conn.json)
PASSWORD=$(jq -r '.password' conn.json)

This is an example to connect to the MongoDB cluster with Mongo shell. Use the CA from mkcert and the certificate from the previous step.

kubectl port-forward svc/mongodb-replica-set-svc 27017:27017 &

mongosh --tlsCAFile /root/.local/share/mkcert/rootCA.pem "mongodb://$USERNAME:$PASSWORD@localhost:27017/admin?directConnection=true&ssl=true"

Documentation and Resources

• Deploy and configure MongoDB resources
• Create a database user with SCRAM authentication
• Secure MongoDB resource connections using TLS
• Enable External Access to a MongoDB Deployment

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.