• Deploy and Configure MongoDB Database Resources >
• Secure a Database Resource >
• Secure Deployments using TLS

Secure Deployments using TLS

The MongoDB Enterprise Kubernetes Operator can use TLS certificates to encrypt connections between:

• MongoDB hosts in a replica set or sharded cluster
• Client applications and MongoDB deployments

This guide instructs you on how to configure the Kubernetes Operator to use TLS for its MongoDB instances.

Prerequisites

Before you secure your MongoDB deployment using TLS encryption, complete the following:

• Install the Kubernetes Operator
• Create Credentials for the Kubernetes Operator
• Deploy the Database Resource that you want to secure:
  • Replica Set
  • Sharded Cluster

Note

You can’t secure a Standalone Instance.

Configure TLS for a Replica Set

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:

copy

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

2

Copy the highlighted section of this replica set resource.

Change the highlighted settings of this YAML file to match your desired replica set configuration.

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-replica-set>
spec:
  members: 3
  version: 4.2.1
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: ReplicaSet
  persistent: true

copy

  security:
    tls:
      enabled: true
...

3

Paste the copied example section into your existing replica set resource.

Open your preferred text editor and paste the object specification at the end of your resource file in the spec section.

4

Configure the TLS settings for your replica set resource.

To enable TLS in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .tls.enabled	boolean	Optional	If this value is true, TLS is enabled on the MongoDB deployment. By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections.	true

5

Save your replica set config file.

6

Update and restart your replica set deployment.

Invoke the following Kubernetes command to update and restart your replica set:

copy

kubectl apply -f <replica-set-conf>.yaml

7

Check the status of your deployment.

The Kubernetes Operator creates the MongoDB resources and requests the Kubernetes Certificate Authority to approve the database host’s certificates. Run the following command to verify that the certificates are pending approval:

copy

kubectl get mdb <resource-name> -o yaml -w

The status field of the output should resemble the following:

status:
  lastTransition: 2019-05-01T15:36:59Z
  message: Not all certificates have been approved by Kubernetes CA
  phase: Failed
  type: ""
  version: ""

If you do not see the status.message above, see Troubleshooting the Kubernetes Operator to help diagnose the issue.

8

Retrieve the CSRs for each host and agent in your deployment.

Invoke the following command to retrieve the CSRs for each host:

copy

kubectl get csr

The command’s output resembles the following:

NAME                                        AGE       REQUESTOR                                                   CONDITION
my-secure-rs-0.mongodb                      33s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-1.mongodb                      31s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-2.mongodb                      24s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending

9

Approve the CSR for each host in your deployment.

Using the values returned in the NAME column, approve each certificate from the previous command’s output using the following command:

copy

kubectl certificate approve <NAME>

Example

The following commands approve the CSRs for the replica set example:

copy

kubectl certificate approve my-secure-rs-0.mongodb
kubectl certificate approve my-secure-rs-1.mongodb
kubectl certificate approve my-secure-rs-2.mongodb

kubectl prints a message to the console when a certificate is approved.

10

Track the status of your deployment.

To check the status of your MongoDB Kubernetes resource, invoke the following command:

copy

kubectl get mdb <resource-name> -o yaml -w

The -w flag means “watch”. With the “watch” flag set, the output refreshes immediately when something changes until the status phase achieves the Running state.

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

Configure TLS for a Sharded Cluster

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:

copy

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

2

Copy the highlighted section of this sharded cluster resource.

Change the highlighted settings of this YAML file to match your desired sharded cluster configuration.

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-sharded-cluster>
spec:
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 4.2.1
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: ShardedCluster
  persistent: true

copy

  security:
    tls:
      enabled: true
...

3

Paste the copied example section into your existing sharded cluster resource.

Open your preferred text editor and paste the object specification at the end of your resource file in the spec section.

4

Configure the TLS settings for your sharded cluster resource.

To enable TLS in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .tls.enabled	boolean	Optional	If this value is true, TLS is enabled on the MongoDB deployment. By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections.	true

5

Save your sharded cluster config file.

6

Update and restart your sharded cluster deployment.

Invoke the following Kubernetes command to update and restart your sharded cluster:

copy

kubectl apply -f <sharded-cluster-conf>.yaml

7

Check the status of your deployment.

The Kubernetes Operator creates the MongoDB resources and requests the Kubernetes Certificate Authority to approve the database host’s certificates. Run the following command to verify that the certificates are pending approval:

copy

kubectl get mdb <resource-name> -o yaml -w

The status field of the output should resemble the following:

status:
  lastTransition: 2019-05-01T15:36:59Z
  message: Not all certificates have been approved by Kubernetes CA
  phase: Failed
  type: ""
  version: ""

If you do not see the status.message above, see Troubleshooting the Kubernetes Operator to help diagnose the issue.

8

Retrieve the CSRs for each host and agent in your deployment.

Invoke the following command to retrieve the CSRs for each host:

copy

kubectl get csr

The command’s output resembles the following:

NAME                                        AGE       REQUESTOR                                                   CONDITION
my-secure-sc-0-0.mongodb                    30s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-0-1.mongodb                    28s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-0-2.mongodb                    27s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-1-0.mongodb                    22s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-1-1.mongodb                    13s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-1-2.mongodb                    6s        system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-config-0.mongodb               36s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-config-1.mongodb               34s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-config-2.mongodb               32s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-mongos-0.mongodb               49s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-mongos-1.mongodb               42s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending

9

Approve the CSR for each host in your deployment.

Using the values returned in the NAME column, approve each certificate from the previous command’s output using the following command:

copy

kubectl certificate approve <NAME>

Example

The following commands approve the CSRs for the sharded cluster example:

copy

kubectl certificate approve my-secure-sc-0-0.mongodb
kubectl certificate approve my-secure-sc-0-1.mongodb
kubectl certificate approve my-secure-sc-0-2.mongodb
kubectl certificate approve my-secure-sc-1-0.mongodb
kubectl certificate approve my-secure-sc-1-1.mongodb
kubectl certificate approve my-secure-sc-1-2.mongodb
kubectl certificate approve my-secure-sc-config-0.mongodb
kubectl certificate approve my-secure-sc-config-1.mongodb
kubectl certificate approve my-secure-sc-config-2.mongodb
kubectl certificate approve my-secure-sc-mongos-0.mongodb
kubectl certificate approve my-secure-sc-mongos-1.mongodb

kubectl prints a message to the console when a certificate is approved.

10

Track the status of your deployment.

To check the status of your MongoDB Kubernetes resource, invoke the following command:

copy

kubectl get mdb <resource-name> -o yaml -w

The -w flag means “watch”. With the “watch” flag set, the output refreshes immediately when something changes until the status phase achieves the Running state.

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

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.