- Deploy and Configure MongoDB Database Resources >
- Secure a Database Resource >
- Secure Deployments using TLS
Secure Deployments using TLS¶
On this page
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
Note
You can’t secure a Standalone Instance of MongoDB in a Kubernetes cluster.
This guide instructs you on how to configure the Kubernetes Operator to use TLS for its MongoDB instances.
Deprecation Notice
Automatically generating TLS certificates with the Kubernetes Operator is deprecated and will be removed in a future release.
You must provide certificates from your own CA, as described in the following procedures, for production environments.
General Prerequisites¶
Before you secure your MongoDB deployment using TLS encryption, complete the following:
Configure TLS 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
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
To create the PEM file, concatenate the TLS certificate and the Private Key. An example of a PEM file would resemble:
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 ofmetadata.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.
- Replace
- End the PEM files with
-pem
and not.pem
. These files shouldn’t have a file extension.
- Name these files the exact names provided, substituting the
appropriate variables. If a filename doesn’t match, deployment
errors occur.
Procedure¶
Copy the highlighted section of this replica set resource.¶
Change the highlighted settings of this YAML file to match your desired replica set configuration.
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.
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 |
boolean | Optional | If this value is By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections. |
true |
spec.security |
string | Optional | If you use a custom CA and have created the ConfigMap that stores it, add the ConfigMap’s name. | <custom-ca> |
Save your replica set config file.¶
Apply your changes to your replica set deployment.¶
Invoke the following Kubernetes command to updated your replica set:
Track the status of your deployment.¶
To check the status of your MongoDB Kubernetes resource, invoke the following command:
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¶
Prerequisites¶
Before you secure your replica set 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
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 ofmetadata.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.
- Replace
- End the PEM files with
-pem
and not.pem
. These files shouldn’t have a file extension.
- Name these files the exact names provided, substituting the
appropriate variables. If a filename doesn’t match, deployment
errors occur.
Procedure¶
Create the secret for your Shards’ TLS certificates.¶
Run this kubectl
command to create the secret that stores
the sharded cluster shards’ certificates:
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.
Copy the highlighted section of this sharded cluster resource.¶
Change the highlighted settings of this YAML file to match your desired sharded cluster configuration.
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.
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 |
boolean | Optional | If this value is By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections. |
true |
spec.security |
string | Optional | If you use a custom CA and have created the ConfigMap that stores it, add the ConfigMap’s name. | <custom-ca> |
Save your sharded cluster config file.¶
Update and restart your sharded cluster deployment.¶
Invoke the following Kubernetes command to update and restart your sharded cluster:
Track the status of your deployment.¶
To check the status of your MongoDB Kubernetes resource, invoke the following command:
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.