Secure Internal Authentication with X.509
On this page
- General Prerequisites
- Configure X.509 Internal Authentication for a Replica Set
- Prerequisites
- Enable X.509 Internal Authentication
- Renew Internal Authentication X.509 Certificates for a Replica Set
- Configure X.509 Internal Authentication for a Sharded Cluster
- Prerequisites
- Enable X.509 Internal Authentication
- Renew Internal Authentication X.509 Certificates for a Sharded Cluster
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.
The Kubernetes Operator doesn't support other authentication schemes between MongoDB nodes in a cluster.
Note
You can't secure a Standalone Instance of MongoDB in a Kubernetes cluster.
General Prerequisites
Before you secure any of your MongoDB deployments using TLS encryption, complete the following:
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 X.509, deploy a TLS-encrypted replica set.
Enable X.509 Internal Authentication
Create the secret for your X.509 certificate.
Run this kubectl
command to create a new secret that stores
the replica set's certificate:
kubectl create secret tls <prefix>-<metadata.name>-clusterfile \ --cert=<replica-set-clusterfile-tls-cert> \ --key=<replica-set-clusterfile-tls-key>
Note
You must prefix your secrets with <prefix>-<metadata.name>
.
For example, if you call your deployment my-deployment
and you set
the prefix to mdb
, you must name the TLS secret for the
client TLS communications mdb-my-deployment-cert
. Also,
you must name the TLS secret for internal cluster authentication
(if enabled) mdb-my-deployment-clusterfile
.
Copy the sample replica set resource.
Change the settings of this YAML file to match your desired replica set configuration.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-replica-set> 6 spec: 7 members: 3 8 version: "4.2.2-ent" 9 opsManager: 10 configMapRef: 11 # Must match metadata.name in ConfigMap file 12 name: <configMap.metadata.name> 13 credentials: <mycredentials> 14 type: ReplicaSet 15 persistent: true
16 security: 17 tls: 18 ca: <custom-ca> 19 certsSecretPrefix: <prefix> 20 authentication: 21 enabled: true 22 modes: ["X509"] 23 internalCluster: "X509" 24 ...
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 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:
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 |
---|---|---|---|---|
string | Required | Use this setting to enable X.509 internal cluster authentication. IMPORTANT: Once internal cluster authentication is enabled, it can't be disabled. | X509 |
Save your replica set config file.
Apply your changes to your replica set deployment.
Invoke the following Kubernetes command to update your replica set:
kubectl apply -f <replica-set-conf>.yaml
Track the status of your deployment.
To check the status of your MongoDB
resource, use the following
command:
kubectl get mdb <resource-name> -o yaml -w
With the -w
(watch) flag set, when the configuration changes, the output
refreshes immediately until the status phase achieves the Running
state.
To learn more about resource deployment statuses, see Troubleshoot the Kubernetes Operator.
Renew Internal Authentication X.509 Certificates for a Replica Set
If you have already created certificates, we recommend that you renew them periodically using the following procedure.
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.
Note
If you are deploying an Ops Manager resource in a multi-Kubernetes cluster MongoDB deployment:
Set the
context
to the name of the central cluster, such as:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"
.Set the
--namespace
to the same scope that you used for your multi-Kubernetes cluster MongoDB deployment, such as:kubectl config --namespace "mongodb"
.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
Renew the secret for your TLS certificates.
Run this kubectl
command to renew an existing secret that
stores the replica set's certificates:
kubectl create secret tls <prefix>-<metadata.name>-cert \ --cert=<replica-set-tls-cert> \ --key=<replica-set-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your X.509 certificate.
Run this kubectl
command to renew an existing secret that
stores the replica set's certificate:
kubectl create secret tls <prefix>-<metadata.name>-clusterfile \ --cert=<replica-set-clusterfile-tls-cert> \ --key=<replica-set-clusterfile-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your agents' X.509 certificates.
Run this kubectl
command to renew an existing secret that
stores the agents' X.509 certificates:
kubectl create secret tls <prefix>-<metadata.name>-agent-certs \ --cert=<agent-tls-cert> \ --key=<agent-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
Configure X.509 Internal Authentication for a Sharded Cluster
Prerequisites
Before you secure your sharded cluster using X.509, deploy a TLS-encrypted sharded cluster.
Enable X.509 Internal Authentication
Create the secret for your Shards' X.509 certificates.
Run this kubectl
command to create a new secret that stores
the sharded cluster shards' certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-clusterfile \ --cert=<shard-0-clusterfile-tls-cert> \ --key=<shard-0-clusterfile-tls-cert> kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-clusterfile \ --cert=<shard-1-clusterfile-tls-cert> \ --key=<shard-1-clusterfile-tls-cert>
Create the secret for your config servers' X.509 certificate.
Run this kubectl
command to create a new secret that stores
the sharded cluster config server's certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-clusterfile \ --cert=<config-clusterfile-tls-cert> \ --key=<config-clusterfile-tls-cert>
Create the secret for your mongos server's X.509 certificates.
Run this kubectl
command to create a new secret that stores
the sharded cluster mongos
certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-clusterfile \ --cert=<mongos-clusterfile-tls-cert> \ --key=<mongos-clusterfile-tls-cert>
Copy the sample sharded cluster resource.
Change the settings of this YAML file to match your desired sharded cluster configuration.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-sharded-cluster> 6 spec: 7 shardCount: 2 8 mongodsPerShardCount: 3 9 mongosCount: 2 10 configServerCount: 3 11 version: "4.2.2-ent" 12 opsManager: 13 configMapRef: 14 name: <configMap.metadata.name> 15 # Must match metadata.name in ConfigMap file 16 credentials: <mycredentials> 17 type: ShardedCluster 18 persistent: true
19 security: 20 tls: 21 ca: <custom-ca> 22 certsSecretPrefix: <prefix> 23 authentication: 24 enabled: true 25 modes: ["X509"] 26 internalCluster: "X509" 27 ...
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 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:
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 |
---|---|---|---|---|
string | Required | Use this setting to enable X.509 internal cluster authentication. IMPORTANT: Once internal cluster authentication is enabled, it can't be disabled. | X509 |
Save your sharded cluster config file.
Update and restart your sharded cluster deployment.
In any directory, invoke the following Kubernetes command to update and restart your sharded cluster:
kubectl apply -f <sharded-cluster-conf>.yaml
Track the status of your deployment.
To check the status of your MongoDB
resource, use the following
command:
kubectl get mdb <resource-name> -o yaml -w
With the -w
(watch) flag set, when the configuration changes, the output
refreshes immediately until the status phase achieves the Running
state.
To learn more about resource deployment statuses, see Troubleshoot the Kubernetes Operator.
Renew Internal Authentication X.509 Certificates for a Sharded Cluster
If you have already created certificates, we recommend that you renew them periodically using the following procedure.
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.
Note
If you are deploying an Ops Manager resource in a multi-Kubernetes cluster MongoDB deployment:
Set the
context
to the name of the central cluster, such as:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"
.Set the
--namespace
to the same scope that you used for your multi-Kubernetes cluster MongoDB deployment, such as:kubectl config --namespace "mongodb"
.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
Renew the secret for your Shards' TLS certificates.
Run this kubectl
command to renew an existing secret that
stores the sharded cluster shards' certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \ --cert=<shard-0-tls-cert> \ --key=<shard-0-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f - kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \ --cert=<shard-1-tls-cert> \ --key=<shard-1-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your config server's TLS certificates.
Run this kubectl
command to renew an existing secret that
stores the sharded cluster config server's certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \ --cert=<config-tls-cert> \ --key=<config-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your mongos server's TLS certificates.
Run this kubectl
command to renew an existing secret that
stores the sharded cluster mongos
certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \ --cert=<mongos-tls-cert> \ --key=<mongos-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your Shards' X.509 certificates.
Run this kubectl
command to renew an existing secret that stores
the sharded cluster shards' certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-clusterfile \ --cert=<shard-0-clusterfile-tls-cert> \ --key=<shard-0-clusterfile-tls-cert> \ --dry-run=client \ -o yaml | kubectl apply -f - kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-clusterfile \ --cert=<shard-1-clusterfile-tls-cert> \ --key=<shard-1-clusterfile-tls-cert> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your config servers' X.509 certificate.
Run this kubectl
command to renew an existing secret that stores
the sharded cluster config servers' certificate:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-clusterfile \ --cert=<config-clusterfile-tls-cert> \ --key=<config-clusterfile-tls-cert> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your mongos server's X.509 certificates.
Run this kubectl
command to renew an existing secret that stores
the sharded cluster mongos
certificates:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-clusterfile \ --cert=<mongos-clusterfile-tls-cert> \ --key=<mongos-clusterfile-tls-cert> \ --dry-run=client \ -o yaml | kubectl apply -f -
Renew the secret for your agents' X.509 certificates.
Run this kubectl
command to renew an existing secret that
stores the agents' X.509 certificates:
kubectl create secret tls <prefix>-<metadata.name>-agent-certs \ --cert=<agent-tls-cert> \ --key=<agent-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -