For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.

Set Up a cert-manager Integration

cert-manager simplifies and automates the management of security certificates for Kubernetes. The following procedure describes how to configure cert-manager to generate certificates for MongoDB Kubernetes Operator resources.

To deploy a replica set using an object, you must:

Note

To avoid storing secrets in single-cluster Kubernetes deployments, you can migrate all secrets to a secret storage tool. Deployments on multiple Kubernetes clusters don't support storing secrets in secret storage tools, such as HashiCorp Vault.

  • Generate one TLS certificate for each of the following components:

    • Your replica set. Ensure that you add SANs for each Kubernetes pod that hosts a member of your replica set to the certificate.

      In your TLS certificate, the SAN for each pod must use the following format:

      <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local

      Important

      If you're using an ACME based service provider such as Let's Encrypt to issue TLS certificates, the provider might prohibit you from adding the Pod's default FQDNs (*.svc.cluster.local) to SANs in the certificate.

      To use an ACME based certificate, you must configure the certificate for your replica set resource. To learn more, see the step about ACME based TLS certificates in the procedure.

    • Your project's MongoDB Agent. For the MongoDB Agent certificate, ensure that you meet the following requirements:

      • The Common Name in the TLS certificate is not empty.

      • The combined Organization and Organizational Unit in each TLS certificate differs from the Organization and Organizational Unit in the TLS certificate for your replica set members.

  • You must have the CA certificate file and name it ca-pem.

  • You must have the key that you used to sign your TLS certificates.

Important

The Kubernetes Operator uses kubernetes.io/tls secrets to store TLS certificates and private keys for Ops Manager and MongoDB resources. Starting in Kubernetes Operator version 1.17.0, the Kubernetes Operator doesn't support concatenated PEM files stored as Opaque secrets.

1

Note

The following steps assume that you have already created a custom CA along with the corresponding tls.key private key and tls.crt signed certificate.

Create a secret to store your CA data:

apiVersion: v1kind: Secretmetadata: name: ca-key-pair namespace: <namespace>data: tls.crt: <your-CA-certificate> tls.key: <your-CA-private-key>
2

If your Ops Manager TLS certificate is signed by a custom CA, the CA certificate must also contain additional certificates that allow Ops Manager Backup Daemon to download MongoDB binaries from the Internet. To create the TLS certificate(s), create a ConfigMap to hold the CA certificate:

Important

The Kubernetes Operator requires that your Ops Manager certificate is named mms-ca.crt in the ConfigMap.

  1. Obtain the entire TLS certificate chain for Ops Manager from downloads.mongodb.com. The following openssl command outputs the certificate in the chain to your current working directory, in .crt format:

    openssl s_client -showcerts -verify 2 \-connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \| awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}'
  2. Concatenate your CA's certificate file for Ops Manager with the entire TLS certificate chain from downloads.mongodb.com that you obtained in the previous step:

    cat <custom_ca_cert.pem> cert2.crt cert3.crt cert4.crt >> mms-ca.crt

    Note

    • Replace the placeholder <custom_ca_cert.pem> with your custom CA certificate PEM file.

    • Don't include your cert1.crt file, as it is your server certificate from MongoDB that shouldn't be included.

  3. Create the ConfigMap for Ops Manager:

    kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
3
  1. Create a CA issuer that references your CA secret:

    apiVersion: cert-manager.io/v1kind: Issuermetadata: name: ca-issuer namespace: <namespace>spec: ca: secretName: ca-key-pair
  2. Verify that the issuer is ready:

    kubectl get issuer ca-issuer

    The READY field in the output should have a value of True.

4

Create a ConfigMap containing your CA. It must have two fields, ca-pem and mms-ca.crt, both pointing to your CA certificate. Replace <CA-certificate> with the path to your CA certificate.

kubectl create cm ca-issuer --from-file=ca-pem=<CA-certificate> \--from-file=mms-ca.crt=<CA-certificate>
5

To secure a MongoDB resource with your generated certification, you must create certificates for both the resource itself and the MongoDB agent.

  1. Create the MongoDB resource certificate. The following example assumes a replica set named my-replica-set with three members:

    Note

    The spec.issuerRef.name parameter references the previously created CA ConfigMap.

    apiVersion: cert-manager.io/v1kind: Certificatemetadata: name: my-replica-set-certificate namespace: mongodbspec: dnsNames: - my-replica-set-0 - my-replica-set-0.my-replica-set-svc.mongodb.svc.cluster.local - my-replica-set-1 - my-replica-set-1.my-replica-set-svc.mongodb.svc.cluster.local - my-replica-set-2 - my-replica-set-2.my-replica-set-svc.mongodb.svc.cluster.local duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: mdb-my-replica-set-cert usages: - server auth - client auth

    For sharded clusters, you must create one certificate for each StatefulSet. To learn more about sharded cluster configuration, see Deploy a Sharded Cluster.

  2. Create the MongoDB agent certificate:

    Note

    The spec.issuerRef.name parameter references the previously created CA ConfigMap.

    apiVersion: cert-manager.io/v1kind: Certificatemetadata: name: agent-certs namespace: mongodbspec: commonName: automation dnsNames: - automation duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: mdb-my-replica-set-agent-certs usages: - digital signature - key encipherment - client auth subject: countries: - US localities: - NY organizationalUnits: - a-1635241837-m5yb81lfnrz organizations: - cluster.local-agent provinces: - NY
  3. Create the MongoDB resource:

    Note

    If you leave the spec.security.tls.ca parameter unspecified, it defaults to {replica-set}-ca.

    apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: my-replica-set namespace: mongodbspec: type: ReplicaSet members: 3 version: 8.0.0 opsManager: configMapRef: name: my-project credentials: my-credentials security: certsSecretPrefix: mdb authentication: enabled: true modes: - X509 tls: ca: ca-issuer enabled: true
6

To secure an Ops Manager resource, you must first create certificates for Ops Manager and AppDB, then create the Ops Manager resource.

  1. Create the Ops Manager certificate:

    Note

    The spec.issuerRef.name parameter references the previously created CA ConfigMap.

    apiVersion: cert-manager.io/v1kind: Certificatemetadata: name: cert-for-ops-manager namespace: mongodbspec: dnsNames: - om-with-https-svc.mongodb.svc.cluster.local duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: mdb-om-with-https-cert usages: - server auth - client auth
  2. Create the AppDB certificate:

    Note

    The spec.issuerRef.name parameter references the previously created CA ConfigMap.

    apiVersion: cert-manager.io/v1kind: Certificatemetadata: name: appdb-om-with-https-db-cert namespace: mongodbspec: dnsNames: - om-with-https-db-0 - om-with-https-db-0.om-with-https-db-svc.mongodb.svc.cluster.local - om-with-https-db-1 - om-with-https-db-1.om-with-https-db-svc.mongodb.svc.cluster.local - om-with-https-db-2 - om-with-https-db-2.om-with-https-db-svc.mongodb.svc.cluster.local duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: appdb-om-with-https-db-cert usages: - server auth - client auth
  3. Create the Ops Manager resource:

    apiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata: name: om-with-https namespace: mongodbspec: adminCredentials: ops-manager-admin-secret version: "8.0.0" applicationDatabase: members: 3 security: certsSecretPrefix: appdb tls: ca: ca-issuer version: 8.0.0-ubi8 replicas: 1 security: certsSecretPrefix: mdb tls: ca: ca-issuer

cert-manager will renew certificates under the following circumstances:

  • The certificate expires according to its spec.duration and spec.renewBefore fields.

  • You delete the secret holding a certificate. In this case, cert-manager recreates the secret according to the configuration in your certificate custom resource.

  • You alter the configuration of the certificate custom resource. In this case, cert-manager recreates the secret that contains the certificate when it detects the changes to its configuration.