• Deploy and Configure MongoDB Database Resources >
• Secure a Database Resource >
• Secure Internal Authentication with X.509 and TLS

Secure Internal Authentication with X.509 and TLS

This guide instructs you on how to configure:

• X.509 internal authentication between MongoDB nodes in a cluster.
• X.509 authentication from clients to your MongoDB instances.
• TLS to encrypt connections between MongoDB hosts in a replica set or sharded cluster.
• TLS to encrypt connections client applications and MongoDB deployments.

Note

You can’t secure a Standalone Instance of MongoDB in a Kubernetes cluster.

To secure your deployment using TLS and X.509 authentication, you may use Kubernetes’s CA or your own CA:

• Kubernetes CA
• Own CA

General Prerequisites

Before you secure any of your MongoDB deployments using TLS encryption, complete the following:

• Install the Kubernetes Operator
• Create Credentials for the Kubernetes Operator

Enabling X.509 authentication at the project level configures all agents to use X.509 client authentication when communicating with MongoDB deployments.

X.509 client authentication requires one of the following:

• Cloud Manager
• Ops Manager 4.1.7 or later
• Ops Manager 4.0.11 or later

Configure X.509 Internal Authentication for a Replica Set

Prerequisites

Before you secure your replica set using TLS encryption, complete the following:

• Deploy the Replica Set that you want to secure

• Deploy the Replica Set that you want to secure

• Create a PEM file for each of the following components:

  PEM file purpose	Save File As…
  Your custom CA	ca-pem
  Each member of your replica set	<metadata.name>-<X>-pem
  Your project’s Automation or MongoDB Agent	mms-automation-agent-pem
  Your project’s Backup Agent (if needed)	mms-backup-agent-pem
  Your project’s Monitoring Agent (if needed)	mms-monitoring-agent-pem

  About the example filenames

  • Name these files the exact names provided, substituting the appropriate variables. If a filename doesn’t match, deployment errors occur.
    • Replace <metadata.name> with the value of metadata.name in your deployment resource.
    • Replace <Y> with a 0-based number for the sharded cluster.
    • Replace <X> with the member of a shard or replica set.
  • End the PEM files with -pem and not .pem. These files shouldn’t have a file extension.

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:

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.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: ReplicaSet
  persistent: true

copy

  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["X509"]
      internalCluster: "X509"
...

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	Set this value to true to enable TLS on the MongoDB deployment. By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections.	true

5

Configure the general X.509 settings for your replica set resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .enabled	boolean	Optional	If this value is true, authentication is enabled on the MongoDB deployment.	true
spec.security .authentication .modes	array	Conditional	If you enabled authentication, you must set an authentication mechanism. Accepted values are X509.	X509

6

Configure the internal X.509 settings for your replica set resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .internalCluster	string	Conditional	If you enabled authentication, you can enable X.509 internal cluster authentication. Accepted values are X509. Important Once internal cluster authentication is enabled, it can not be disabled.	X509

7

Save your replica set config file.

8

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

9

Check the status of your deployment.

The Kubernetes Operator creates the MongoDB resources and requests the Kubernetes CA 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.

10

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
mms-automation-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-backup-agent.mongodb                    15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-monitoring-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
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

11

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.

12

Retrieve the cluster file CSR for each host in your deployment.

When spec.security.clusterAuthenticationMode is set to x509, Kubernetes Operator generates an additional CSR per host for the clusterfile.

After the first batch of certificates are approved, run the command to retrieve the CSRs again:

copy

kubectl get csr

The clusterfile CSRs are now present in the output:

NAME                                        AGE       REQUESTOR                                                   CONDITION
mms-automation-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-backup-agent.mongodb                    15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-monitoring-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-rs-0-clusterfile.mongodb          13s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-0.mongodb                      105s      system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-rs-1-clusterfile.mongodb          7s        system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-1.mongodb                      103s      system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-rs-2-clusterfile.mongodb          3s        system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-2.mongodb                      100s      system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued

Note

The Kubernetes Operator generates CSRs for the MongoDB Agents when MongoDB resources are present.

13

Approve the cluster file CSR for each host in your deployment.

Approve the clusterfile CSRs using the same command:

copy

kubectl certificate approve <NAME>

Example

The following commands approve the clusterfile certificates:

copy

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

14

Approve the CSR for each agent 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 mms-automation-agent.mongodb
kubectl certificate approve mms-backup-agent.mongodb
kubectl certificate approve mms-monitoring-agent.mongodb

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

15

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.

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

Create the secret for your TLS certificates.

Run this kubectl command to create the secret that stores the replica set’s certificates:

copy

kubectl create secret generic <metadata.name>-cert \
  --from-file=<metadata.name>-0-pem \
  --from-file=<metadata.name>-1-pem \
  --from-file=<metadata.name>-2-pem

This example covers a three-member replica set. If you have more than three members, you can add them to the certificate using the --from-file option.

3

Create the secret for your X.509 certificates.

Run this kubectl command to create the secret that stores the replica set’s certificates:

copy

kubectl create secret generic <metadata.name>-clusterfile \
  --from-file=<metadata.name>-0-pem \
  --from-file=<metadata.name>-1-pem \
  --from-file=<metadata.name>-2-pem

This example covers a three-member replica set. If you have more than three members, you can add them to the certificate using the --from-file option.

4

Create the ConfigMap to link your CA with your deployment.

Run this kubectl command to link your CA to your replica set:

copy

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

5

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.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: ReplicaSet
  persistent: true

copy

  security:
    tls:
      enabled: true
      ca: <custom-ca>
    authentication:
      enabled: true
      modes: ["X509"]
      internalCluster: "X509"
...

6

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.

7

Configure the TLS settings for your replica set resource using a Custom Certificate Authority.

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
spec.security .tls.ca	string	Optional	If you use a custom CA and have created the secret that stores it, add the secret’s name.	<custom-ca>

8

Configure the general X.509 settings for your replica set resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .enabled	boolean	Optional	If this value is true, authentication is enabled on the MongoDB deployment.	true
spec.security .authentication .modes	array	Conditional	If you enabled authentication, you must set an authentication mechanism. Accepted values are X509.	X509

9

Configure the internal X.509 settings for your replica set resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .internalCluster	string	Conditional	If you enabled authentication, you can enable X.509 internal cluster authentication. Accepted values are X509. Important Once internal cluster authentication is enabled, it can not be disabled.	X509

10

Save your replica set config file.

11

Apply your changes to your replica set deployment.

Invoke the following Kubernetes command to updated your replica set:

copy

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

12

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 X.509 Internal Authentication for a Sharded Cluster

Prerequisites

Before you secure your sharded cluster using TLS encryption, complete the following:

• Deploy the Sharded Cluster that you want to secure

• Create a PEM file for each of the following components:

  PEM file purpose	Save File As…
  Your custom CA	ca-pem
  Each shard in your sharded cluster	<metadata.name>-<Y>-<X>-pem
  Each member of your config server replica set	<metadata.name>-config-<X>-pem
  Each mongos	<metadata.name>-mongos-<X>-pem
  Your project’s Automation or MongoDB Agent	mms-automation-agent-pem
  Your project’s Backup Agent (if needed)	mms-backup-agent-pem
  Your project’s Monitoring Agent (if needed)	mms-monitoring-agent-pem

  About the example filenames

  • Name these files the exact names provided, substituting the appropriate variables. If a filename doesn’t match, deployment errors occur.
    • Replace <metadata.name> with the value of metadata.name in your deployment resource.
    • Replace <Y> with a 0-based number for the sharded cluster.
    • Replace <X> with the member of a shard or replica set.
  • End the PEM files with -pem and not .pem. These files shouldn’t have a file extension.

• Deploy the Sharded Cluster that you want to secure

• Create a PEM file for each of the following components:

  PEM file purpose	Save File As…
  Your custom CA	ca-pem
  Each shard in your sharded cluster	<metadata.name>-<Y>-<X>-pem
  Each member of your config server replica set	<metadata.name>-config-<X>-pem
  Each mongos	<metadata.name>-mongos-<X>-pem
  Your project’s Automation or MongoDB Agent	mms-automation-agent-pem
  Your project’s Backup Agent (if needed)	mms-backup-agent-pem
  Your project’s Monitoring Agent (if needed)	mms-monitoring-agent-pem

  About the example filenames

  • Name these files the exact names provided, substituting the appropriate variables. If a filename doesn’t match, deployment errors occur.
    • Replace <metadata.name> with the value of metadata.name in your deployment resource.
    • Replace <Y> with a 0-based number for the sharded cluster.
    • Replace <X> with the member of a shard or replica set.
  • End the PEM files with -pem and not .pem. These files shouldn’t have a file extension.

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:

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.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: ShardedCluster
  persistent: true

copy

  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["X509"]
      internalCluster: "X509"
...

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	Set this value to true to enable TLS on the MongoDB deployment. By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections.	true

5

Configure the general X.509 settings for your sharded cluster resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .enabled	boolean	Optional	If this value is true, authentication is enabled on the MongoDB deployment.	true
spec.security .authentication .modes	array	Conditional	If you enabled authentication, you must set an authentication mechanism. Accepted values are X509.	X509

6

Configure the internal X.509 settings for your sharded cluster resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .internalCluster	string	Conditional	If you enabled authentication, you can enable X.509 internal cluster authentication. Accepted values are X509. Important Once internal cluster authentication is enabled, it can not be disabled.	X509

7

Save your sharded cluster config file.

8

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

9

Check the status of your deployment.

The Kubernetes Operator creates the MongoDB resources and requests the Kubernetes CA 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.

10

Retrieve the CSRs for each host 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
mms-automation-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-backup-agent.mongodb                    15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-monitoring-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
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

11

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.

12

Retrieve the cluster file CSR for each host in your deployment.

When spec.security.clusterAuthenticationMode is set to x509, Kubernetes Operator generates an additional CSR per host for the clusterfile.

After the first batch of certificates are approved, run the command to retrieve the CSRs again:

copy

kubectl get csr

The clusterfile CSRs are now present in the output:

NAME                                        AGE       REQUESTOR                                                   CONDITION
mms-automation-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-backup-agent.mongodb                    15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
mms-monitoring-agent.mongodb                15m       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-0-0-clusterfile.mongodb        40s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-0-0.mongodb                    2m22s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-0-1-clusterfile.mongodb        36s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-0-1.mongodb                    2m20s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-0-2-clusterfile.mongodb        32s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-0-2.mongodb                    2m19s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-1-0-clusterfile.mongodb        27s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-1-0.mongodb                    2m14s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-1-1-clusterfile.mongodb        23s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-1-1.mongodb                    2m5s      system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-1-2-clusterfile.mongodb        20s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-1-2.mongodb                    118s      system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-config-0-clusterfile.mongodb   10s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-config-0.mongodb               2m28s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-config-1-clusterfile.mongodb   5s        system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-config-1.mongodb               2m26s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-config-2-clusterfile.mongodb   2s        system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-config-2.mongodb               2m24s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-mongos-0-clusterfile.mongodb   18s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-mongos-0.mongodb               2m41s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved,Issued
my-secure-sc-mongos-1-clusterfile.mongodb   12s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-sc-mongos-1.mongodb               2m34s     system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending

Note

The Kubernetes Operator generates CSRs for the MongoDB Agents when MongoDB resources are present.

13

Approve the cluster file CSR for each host in your deployment.

Approve the clusterfile CSRs using the same command:

copy

kubectl certificate approve <NAME>

Example

The following commands approve the clusterfile certificates:

copy

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

14

Approve the CSR for each agent 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 mms-automation-agent.mongodb
kubectl certificate approve mms-backup-agent.mongodb
kubectl certificate approve mms-monitoring-agent.mongodb

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

15

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.

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

Create the secret for your Shards’ TLS certificates.

Run this kubectl command to create the secret that stores the sharded cluster shards’ certificates:

copy

kubectl -n mongodb create secret generic <metadata.name>-0-cert \
       --from-file=<metadata.name>-0-0-pem \
       --from-file=<metadata.name>-0-1-pem \
       --from-file=<metadata.name>-0-2-pem \
       --from-file=<metadata.name>-0-3-pem \
       --from-file=<metadata.name>-0-4-pem

kubectl -n mongodb create secret generic <metadata.name>-1-cert \
       --from-file=<metadata.name>-1-0-pem \
       --from-file=<metadata.name>-1-1-pem \
       --from-file=<metadata.name>-1-2-pem \
       --from-file=<metadata.name>-1-3-pem \
       --from-file=<metadata.name>-1-4-pem

This example covers a two-shard sharded cluster with five members per shard. If you have more than two shards or five members per shard, you can add them to the certificate using the --from-file option.

3

Create the secret for your config server’s TLS certificates.

Run this kubectl command to create the secret that stores the sharded cluster config server’s certificates:

copy

kubectl -n mongodb create secret generic <metadata.name>-config-cert \
       --from-file=<metadata.name>-config-0-pem \
       --from-file=<metadata.name>-config-1-pem \
       --from-file=<metadata.name>-config-2-pem

4

Create the secret for your mongos server’s TLS certificates.

Run this kubectl command to create the secret that stores the sharded cluster mongos certificates:

copy

kubectl -n mongodb create secret generic <metadata.name>-mongos-cert \
       --from-file=<metadata.name>-mongos-0-pem \
       --from-file=<metadata.name>-mongos-1-pem \
       --from-file=<metadata.name>-mongos-2-pem

5

Create the secret for your Shards’ X.509 certificates.

Run this kubectl command to create the secret that stores the sharded cluster shards’ certificates:

copy

kubectl -n mongodb create secret generic <metadata.name>-0-clusterfile \
       --from-file=<metadata.name>-0-0-pem \
       --from-file=<metadata.name>-0-1-pem \
       --from-file=<metadata.name>-0-2-pem \
       --from-file=<metadata.name>-0-3-pem \
       --from-file=<metadata.name>-0-4-pem

kubectl -n mongodb create secret generic <metadata.name>-1-clusterfile \
       --from-file=<metadata.name>-1-0-pem \
       --from-file=<metadata.name>-1-1-pem \
       --from-file=<metadata.name>-1-2-pem \
       --from-file=<metadata.name>-1-3-pem \
       --from-file=<metadata.name>-1-4-pem

This example covers a two-shard sharded cluster with five members per shard. If you have more than two shards or five members per shard, you can add them to the certificate using the --from-file option.

6

Create the secret for your config server’s X.509 certificates.

Run this kubectl command to create the secret that stores the sharded cluster config server’s certificates:

copy

kubectl -n mongodb create secret generic <metadata.name>-config-clusterfile \
       --from-file=<metadata.name>-config-0-pem \
       --from-file=<metadata.name>-config-1-pem \
       --from-file=<metadata.name>-config-2-pem

7

Create the secret for your mongos server’s X.509 certificates.

Run this kubectl command to create the secret that stores the sharded cluster mongos certificates:

copy

kubectl -n mongodb create secret generic <metadata.name>-mongos-clusterfile \
       --from-file=<metadata.name>-mongos-0-pem \
       --from-file=<metadata.name>-mongos-1-pem \
       --from-file=<metadata.name>-mongos-2-pem

8

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.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: ShardedCluster
  persistent: true

copy

  security:
    tls:
      enabled: true
      ca: <custom-ca>
    authentication:
      enabled: true
      modes: ["X509"]
      internalCluster: "X509"
...

9

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.

10

Configure the TLS settings for your sharded cluster resource using a Custom Certificate Authority.

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
spec.security .tls.ca	string	Optional	If you use a custom CA and have created the secret that stores it, add the secret’s name.	<custom-ca>

11

Configure the general X.509 settings for your sharded cluster resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .enabled	boolean	Optional	If this value is true, authentication is enabled on the MongoDB deployment.	true
spec.security .authentication .modes	array	Conditional	If you enabled authentication, you must set an authentication mechanism. Accepted values are X509.	X509

12

Configure the internal X.509 settings for your sharded cluster resource.

To enable TLS and X.509 in your deployment, configure the following settings in your Kubernetes object:

Key	Type	Necessity	Description	Example
spec.security .authentication .internalCluster	string	Conditional	If you enabled authentication, you can enable X.509 internal cluster authentication. Accepted values are X509. Important Once internal cluster authentication is enabled, it can not be disabled.	X509

13

Save your sharded cluster config file.

14

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

15

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.