This version of the documentation is archived and no longer supported.

Sharded Cluster Security

In most respects, security for a sharded cluster is similar to other MongoDB deployments. A sharded cluster uses the same keyfile and access control as all MongoDB deployments. However, there are additional considerations when using authentication with sharded clusters.


In addition to the mechanisms described in this section, always run sharded clusters in a trusted networking environment. Ensure that the network only permits trusted traffic to reach mongos and mongod instances.

Access Control Privileges in Sharded Clusters

In sharded clusters, MongoDB provides separate administrative privileges for the sharded cluster and for each shard.

Sharded Cluster Authentication.

When connected to a mongos, you can grant access to the sharded cluster’s admin database. [1] These credentials reside on the config servers.

Users can access to the cluster according to their permissions. To receive privileges for the cluster, you must authenticate while connected to a mongos instance.

Shard Server Authentication.

To allow administrators to connect and authenticate directly to specific shards, create users in the admin database on the mongod instance, or replica set, that provide each shard.

These users only have access to a single shard and are completely distinct from the cluster-wide credentials.


Always connect and authenticate to sharded clusters via a mongos instance.

Beyond these proprieties, privileges for sharded clusters are functionally the same as any other MongoDB deployment. See Access Control for more information.

[1]Credentials for databases other than the admin database reside in the mongod instance (or replica set) that is the primary shard for that database.

Access a Sharded Cluster with Authentication

To access a sharded cluster as an authenticated user, from the command line, use the authentication options when connecting to a mongos. Or, you can connect first and then authenticate with the authenticate command or the db.auth() method.

To close an authenticated session, see the logout command.

Restriction on localhost Interface

Sharded clusters have restrictions on the use of localhost interface. If the host identifier for a MongoDB instance is either localhost or “”, then you must use “localhost” or “” to identify all MongoDB instances in a deployment.This applies to the host argument to the addShard command as well as to the --configdb option for the mongos. If you mix localhost addresses with remote host address, sharded clusters will not function correctly.