• Deploy Multiple Clusters (Beta) >
• Secure Database Resources in Multi-Cluster Deployments >
• Secure Client Connections in Multi-Cluster Deployments >
• Secure Client Authentication with LDAP in Multi-Cluster Deployments

Secure Client Authentication with LDAP in Multi-Cluster Deployments

MongoDB Enterprise supports:

• Proxying authentication requests to a Lightweight Directory Access Protocol (LDAP) service.
• Simple and SASL binding to LDAP servers. MongoDB Enterprise can bind to an LDAP server via saslauthd or through the operating system libraries.

To learn more, see the LDAP Proxy Authentication and LDAP Authorization sections in the MongoDB Server documentation.

You can use the Kubernetes Operator to configure LDAP to authenticate your client applications that connect to your multi-cluster deployments. This guide describes how to configure LDAP authentication from client applications to your multi-cluster deployments.

Considerations

• To configure LDAP in CustomResourceDefinitions, use the parameters under the spec.security.authentication.ldap and other security LDAP settings specific to the MongoDB Agent, from the Kubernetes Operator MongoDB resource specification. The procedures in this section describe the required settings and provide examples of LDAP configuration.
• To improve security, consider configuring TLS. Encryption with TLS is optional. By default, LDAP traffic is sent as plain text. This means that username and password are exposed to network threats. Many modern directory services, such as Microsoft Active Directory, require encrypted connections. Consider using LDAP over TLS/SSL to encrypt vauthentication requests in your Kubernetes Operator MongoDB deployments.

General Prerequisites

Before you secure your multi-cluster deployment using TLS encryption, complete the following tasks:

• Follow the steps in the Multi-Cluster Quick Start Prerequisites.
• Deploy a multi-cluster using a Multi-Cluster Quick Start.

Configure LDAP Client Authentication for a Multi-Cluster Replica Set

1

Create the secret for the TLS certificate of your MongoDBMulti custom resource.

Run the kubectl command to create a new secret that stores the MongoDB multi-cluster resource’s certificate:

copy

kubectl --context $MDB_CENTRAL_CLUSTER_FULL_NAME \
  --namespace=<metadata.namespace> \
  create secret tls <prefix>-<metadata.name>-cert \
  --cert=<resource-tls-cert> \
  --key=<resource-tls-key>

Note

You must prefix your secrets with <prefix>-<metadata.name>.

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.

If you’re using HashiCorp Vault as your secret storage tool, you can Create a Vault Secret instead.

To learn about your options for secret storage, see Configure Secret Storage.

2

Create the ConfigMap to link your CA with your MongoDBMulti custom resource.

Run the kubectl command to link your CA to your MongoDBMulti custom resource:

copy

kubectl --context $MDB_CENTRAL_CLUSTER_FULL_NAME \
  --namespace=<metadata.namespace> \
  create configmap custom-ca -from-file=ca-pem

3

Update your MongoDBMulti custom resource to enable LDAP authentication.

Update your MongoDBMulti custom resource with security settings from the Kubernetes Operator MongoDB resource specification.

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

Key	Type and necessity	Description	Example
spec.security .authentication.enabled	boolean, required	Set to true to enable LDAP authentication.	true
spec.security .authentication.ldap.bindQueryUser	string, required	Specify the LDAP Distinguished Name to which MongoDB binds when connecting to the LDAP server.	cn=admin,dc=example,dc=org
spec.security .authentication.ldap.bindQueryPasswordSecretRef	string, required	Specify the name of the secret that contains the LDAP Bind Distinguished Name’s password with which MongoDB binds when connecting to an LDAP server.	<secret-name>
spec.security .authentication.ldap.caConfigMapRef.name	string, optional	Add the ConfigMap’s name that stores the custom CA that you used to sign your deployment’s TLS certificates.	<configmap-name>
spec.security .authentication.ldap.caConfigMapRef.key	string, optional	Add the field name that stores the CA which validates the LDAP server’s TLS certificate.	<configmap-key>
spec.security .authentication.ldap.servers	array of strings, required	Specify the list of hostname:port combinations of one or more LDAP servers. For each server, use a separate line.	<example.com:636>
spec.security .authentication.ldap.transportSecurity	string, optional	Set to tls to use LDAPS (LDAP over TLS). Leave blank if your LDAP server doesn’t accept TLS.	tls
spec.security .authentication.ldap.userToDNMapping	string, required	Specify the mapping that maps the username provided to mongod or mongos for authentication to an LDAP Distinguished Name (DN). To learn more, see security.ldap.userToDNMapping and LDAP Query Templates in the MongoDB Server documentation.	<match: "(.+)",substitution: "uid={0},ou=groups,dc=example,dc=org">
spec.security .authentication.modes	string, required	Set to LDAP to enable authentication through LDAP.	LDAP
spec.security .certsSecretPrefix	string, optional	Add the <prefix> of the secret name that contains your MongoDB deployment’s TLS certificates. 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.	devDb
spec.security .tls.ca	string, optional	Add the ConfigMap’s name that stores the custom CA that you used to sign your deployment’s TLS certificates.	<custom-ca>

The resulting configuration may look similar to the following example:

copy

security:
 authentication:
   enabled: true
   # Enabled LDAP Authentication Mode
   modes:
     - "LDAP"
     - "SCRAM"
     # LDAP related configuration
   ldap:
   # Specify the hostname:port combination of one or
   # more LDAP servers
     servers:
       - "ldap1.example.com:636"
       - "ldap2.example.com:636"

   # Set to "tls" to use LDAP over TLS. Leave blank if
   # the LDAP server doesn't accept TLS.
   transportSecurity: "tls"

   # If TLS is enabled, add a reference to a ConfigMap that
   # contains a CA certificate that validates the LDAP server's
   # TLS certificate.
   caConfigMapRef:
     name: "<configmap-name>"
     key: "<configmap-entry-key>"

   # Specify the LDAP Distinguished Name to which
   # MongoDB binds when connecting to the LDAP server
   bindQueryUser: "cn=admin,dc=example,dc=org"

   # Specify the password with which MongoDB binds
   # when connecting to an LDAP server. This is a
   # reference to a Secret Kubernetes Object containing
   # one "password" key.
   bindQueryPasswordSecretRef:
     name: "<secret-name>"

For a full list of LDAP settings, see security settings in the Kubernetes Operator MongoDB resource specification. Also see the spec.security.authentication.agents.automationUserName setting for the MongoDB Agent user in your LDAP-enabled Kubernetes Operator deployment.

4

Verify that the MDB resources are running.

1. For member clusters, run the following commands to verify that the MongoDB Pods are in the running state:

   copy

   kubectl get pods \
    --context=$MDB_CLUSTER_1_FULL_NAME \
    --namespace mongodb
   

   copy

   kubectl get pods \
    --context=$MDB_CLUSTER_2_FULL_NAME \
    --namespace mongodb
   

   copy

   kubectl get pods \
    --context=$MDB_CLUSTER_3_FULL_NAME \
    --namespace mongodb
   

2. In the central cluster, run the following commands to verify that the MongoDBMulti custom resource is in the running state:

   copy

   kubectl --context=$MDB_CENTRAL_CLUSTER_FULL_NAME \
     --namespace mongodb \
     get mdbm multi-replica-set -o yaml -w
   

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