On this page本页内容
MongoDB Enterprise supports authentication using a Kerberos service. Kerberos is an industry standard authentication protocol for large client/server systems. MongoDB Enterprise only supports the MIT implementation of Kerberos.
To verify that you are using MongoDB Enterprise, pass the --version
command line option to the mongod
or mongos
:
In the output from this command, look for the string modules:
subscription
or modules: enterprise
to confirm you are using the MongoDB Enterprise binaries.
For replica sets and sharded clusters, ensure that your configuration uses fully qualified domain names (FQDN) rather than IP addresses or unqualified hostnames. You must use the FQDN for GSSAPI to correctly resolve the Kerberos realms and allow you to connect.
Setting up and configuring a Kerberos deployment is beyond the scope of this document. Please refer to the MIT Kerberos documentation or your operating system documentation for information on how to configure a Kerberos deployment.
In order to use MongoDB with Kerberos, a Kerberos service principal for each mongod
and mongos
instance in your MongoDB deployment must be added to the Kerberos database. You can add the service principal by running a command similar to the following on your KDC:
On each system running mongod
or mongos
, a keytab file must be created for the respective service principal. You can create the keytab file by running a command similar to the following on the system running mongod
or mongos
:
The following procedure outlines the steps to add a Kerberos user principal to MongoDB, configure a standalone mongod
instance for Kerberos support, and connect using the mongo
shell and authenticate the user principal.
mongod
without Kerberos.¶For the initial addition of Kerberos users, start mongod
without Kerberos support.
If a Kerberos user is already in MongoDB and has the privileges required to create a user, you can start mongod
with Kerberos support.
Include additional settings as appropriate to your deployment.
Note
Starting in MongoDB 3.6, mongod
and mongos
bind to localhost by default. If the members of your deployment are run on different hosts or if you wish remote clients to connect to your deployment, you must specify --bind_ip
or net.bindIp
. For more information, see Localhost Binding Compatibility Changes.
Add a Kerberos principal, <username>@<KERBEROS REALM>
or <username>/<instance>@<KERBEROS REALM>
, to MongoDB in the $external
database. Specify the Kerberos realm in all uppercase. The $external
database allows mongod
to consult an external source (e.g. Kerberos) to authenticate. To specify the user’s privileges, assign roles to the user.
Changed in version 3.6.3:To use sessions with $external
authentication users (i.e. Kerberos, LDAP, x.509 users), the usernames cannot be greater than 10k bytes.
The following example adds the Kerberos principal application/reporting@EXAMPLE.NET
with read-only access to the records
database:
Add additional principals as needed. For every user you want to authenticate using Kerberos, you must create a corresponding user in MongoDB. For more information about creating and managing users, see User Management Commands.
mongod
with Kerberos support.¶To start mongod
with Kerberos support, set the environmental variable KRB5_KTNAME
to the path of the keytab file and the mongod
parameter authenticationMechanisms
to GSSAPI
in the following form:
Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the --bind_ip
. For more information, see Localhost Binding Compatibility Changes.
For example, the following starts a standalone mongod
instance with Kerberos support:
The path to your mongod
as well as your keytab file may differ. The keytab file must be only accessible to the owner of the mongod
process.
With the official .deb
or .rpm
packages, you can set the KRB5_KTNAME
in a environment settings file. See KRB5_KTNAME for details.
mongo
shell to mongod
and authenticate.¶Connect the mongo
shell client as the Kerberos principal application/reporting@EXAMPLE.NET
. Before connecting, you must have used Kerberos’s kinit
program to get credentials for application/reporting@EXAMPLE.NET
.
You can connect and authenticate from the command line.
If you are connecting to a system whose hostname matches the Kerberos name, ensure that you specify the fully qualified domain name (FQDN) for the --host
option, rather than an IP address or unqualified hostname.
If you are connecting to a system whose hostname does not match the Kerberos name, use --gssapiHostName
to specify the Kerberos FQDN that it responds to.
Alternatively, you can first connect mongo
to the mongod
, and then from the mongo
shell, use the db.auth()
method to authenticate in the $external
database.
If you installed MongoDB Enterprise using one of the official .deb
or .rpm
packages, and you use the included init/upstart scripts to control the mongod
instance, you can set the KR5_KTNAME
variable in the default environment settings file instead of setting the variable each time.
For .rpm
packages, the default environment settings file is /etc/sysconfig/mongod
.
For .deb
packages, the file is /etc/default/mongodb
.
Set the KRB5_KTNAME
value in a line that resembles the following:
mongos
for Kerberos¶To start mongos
with Kerberos support, set the environmental variable KRB5_KTNAME
to the path of its keytab file and the mongos
parameter authenticationMechanisms
to GSSAPI
in the following form:
Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the --bind_ip
. For more information, see Localhost Binding Compatibility Changes.
For example, the following starts a mongos
instance with Kerberos support:
The path to your mongos
as well as your keytab file may differ. The keytab file must be only accessible to the owner of the mongos
process.
Modify or include any additional mongos
options as required for your configuration. For example, instead of using --keyFile
for internal authentication of sharded cluster members, you can use x.509 member authentication instead.
To configure mongod
or mongos
for Kerberos support using a configuration file, specify the authenticationMechanisms
setting in the configuration file.
If using the YAML configuration file format:
Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the net.bindIp
setting. For more information, see Localhost Binding Compatibility Changes.
For example, if /opt/mongodb/mongod.conf
contains the following configuration settings for a standalone mongod
:
To start mongod
with Kerberos support, use the following form:
The path to your mongod
, keytab file, and configuration file may differ. The keytab file must be only accessible to the owner of the mongod
process.
If you encounter problems when starting mongod
or mongos
with Kerberos authentication, see Troubleshoot Kerberos Authentication.
Kerberos authentication (GSSAPI (Kerberos)) can work alongside:
Specify the mechanisms as follows:
Only add the other mechanisms if in use. This parameter setting does not affect MongoDB’s internal authentication of cluster members.
After completing the configuration steps, you can validate your configuration with the mongokerberos
tool.
Introduced alongside MongoDB 4.4, mongokerberos
provides a convenient method to verify your platform’s Kerberos configuration for use with MongoDB, and to test that Kerberos authentication from a MongoDB client works as expected. See the mongokerberos
documentation for more information.
mongokerberos
is available in MongoDB Enterprise only.