Navigation

Secure Application Database using TLS

On this page

The MongoDB Enterprise Kubernetes Operator can use TLS certificates to encrypt connections between members of the application database replica set.

Prerequisites

Before you secure your application database using TLS encryption, complete the following:

  • Install the Kubernetes Operator.

  • Deploy the Ops Manager application that you want to secure.

  • Create one TLS certificate for the Application Database’s replica set.

    This TLS certificate requires the following attributes:

    DNS Names

    Ensure that you add SANs or Subject Names for each Pod that hosts a member of the Application Database replica set. The SAN for each pod must use the following format:

    <opsmgr-metadata.name>-db-<index>.<opsmgr-metadata.name>-db-svc.<namespace>.svc.cluster.local
    
    Key Usages

    Ensure that the TLS certificates include the following key-usages (5280):

    • “server auth”
    • “client auth”

Important

Starting in version 1.13, the Kubernetes Operator uses kubernetes.io/tls secrets to store TLS certificates and private keys for Ops Manager and MongoDB resources.

Previous Kubernetes Operator versions required you to concatenate your TLS certificates and private keys into a PEM file and store this file in an Opaque secret.

To maintain backwards compatibility, the Kubernetes Operator continues to support storing PEM files in Opaque secrets. Support of this feature might be removed in a future release.

Procedure

1

Configure kubectl to default to your namespace.

If you have not already, run the following command to execute all kubectl commands in the namespace you created:

kubectl config set-context $(kubectl config current-context) --namespace=<namespace>
2

Create a Secret with your Application Database TLS certificate.

Run this kubectl command to create a new secret that stores the Application Database’s TLS certificate:

kubectl create secret tls <metadata.name>-appdb-cert \
  --cert=<appdb-tls-cert> \
  --key=<appdb-tls-key>
3

Optional: Create a ConfigMap that contains the Certificate Authority.

You must provide a CA certificate when the CA that signed the certificates might be not “recognized” as an official authority. You can create valid certificates with cert-manager or HashiCorp Vault.

If you signed the certificates using a Kubernetes certificate management tool, such as cert-manager or HashiCorp Vault, you must create a ConfigMap containing the CA’s certificate file.

If you output the certificate as a file, name this file ca-pem. This simplifies creating the ConfigMap.

Warning

You must concatenate your custom CA file and the entire TLS certificate chain from downloads.mongodb.com to prevent Ops Manager from becoming inoperable if the application database restarts.

  1. Obtain the entire TLS certificate chain from downloads.mongodb.com. The following openssl command outputs each 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 with the entire TLS certificate chain from downloads.mongodb.com that you obtained in the previous step:

    cat cert1.crt cert2.crt cert3.crt cert4.crt  >> ca-pem
    
  3. Create the ConfigMap:

    kubectl create configmap ca --from-file="ca-pem"
    

This creates a ConfigMap named ca. This ConfigMap contains one entry called ca-pem with the contents of the CA file and the certificate chain for downloads.mongodb.com.

4

Specify the Secret with certificates to the Ops Manager yaml definition.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
---
apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: om-appdb-tls-enabled
spec:
  replicas: 1
  version: "5.0.0"
  adminCredentials: ops-manager-admin-secret
  configuration:
    mms.fromEmailAddr: admin@example.com
    mms.security.allowCORS: "false"
  security:
    certsSecretPrefix:  <prefix> # Optional. Text to prefix to the name of the
                                 # secret that contains Ops Manager's TLS 
                                 # certificate. If you omit
                                 # this setting, name the secret 
                                 # <metadata.name>-cert.    
    tls:
      ca: "opsmgr-ca" # Optional. Name of the ConfigMap file
                      # containing the certicate authority that
                      # signs the certificates that the Ops Manager
                      # resource uses.
                      # Ops Manager custom  resource.
  applicationDatabase:
    members: 3
    version: "4.4.0-ent"
      security:
        certsSecretPrefix: <prefix> # Optional. Text to prefix to the 
                                    # name of the secret that contains the Application
                                    # Database's TLS certificate. If you omit
                                    # this setting, name the secret 
                                    # <metadata.name>-appdb-cert.
        tls:
          ca: "appdb-ca" # Optional. Name of the ConfigMap file
                         # containing the certicate authority that
                         # signs the certificates used by the
                         # application database.
...

Note

The Kubernetes Operator mounts the CA you add using the spec.applicationDatabase.security.tls.ca setting to both the Ops Manager and the Application Database pods.

5

Apply changes to your Ops Manager deployment.

Invoke the following kubectl command on the filename of the Ops Manager resource definition:

kubectl apply -f <opsmgr-resource>.yaml
6

Track the status of your Ops Manager instance.

To check the status of your Ops Manager resource, invoke the following command:

kubectl get om -o yaml -w

When Ops Manager is running, the command returns the following output under the status field:

status:
  applicationDatabase:
    lastTransition: "2021-09-06T17:46:15Z"
    members: 3
    phase: Running
    type: ReplicaSet
    version: "4.4.0-ent"
  opsManager:
    lastTransition: "2021-09-06T17:46:32Z"
    phase: Running
    replicas: 1
    url: https://om-appdb-tls-enabled-svc.dev.svc.cluster.local:8443
    version: "5.0.0"

See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.