Database Manual / Self-Managed Deployments / Security / Authentication

Kerberos Authentication on Self-Managed Deployments自我管理部署上的Kerberos身份验证

Overview概述

MongoDB Enterprise provides support for Kerberos authentication of MongoDB clients to mongod and mongos instances. MongoDB Enterprise支持MongoDB客户端对mongodmongos实例的Kerberos身份验证。Kerberos is an industry standard authentication protocol for large client/server systems. Kerberos allows MongoDB and applications to take advantage of existing authentication infrastructure and processes. Kerberos是用于大型客户端/服务器系统的行业标准身份验证协议。Kerberos允许MongoDB和应用程序利用现有的身份验证基础设施和流程。MongoDB Enterprise only supports the MIT implementation of Kerberos.MongoDB Enterprise仅支持Kerberos的MIT实现

Kerberos Components and MongoDBKerberos组件和MongoDB

Principals校长

In a Kerberos-based system, every participant in the authenticated communication is known as a "principal", and every principal must have a unique name.在基于Kerberos的系统中,经过身份验证的通信中的每个参与者都被称为“主体”,每个主体都必须有一个唯一的名称。

Principals belong to administrative units called realms. For each realm, the Kerberos Key Distribution Center (KDC) maintains a database of the realm's principal and the principals' associated "secret keys".主体属于称为领域的行政单位。对于每个领域,Kerberos键分发中心(KDC)维护一个领域主体和主体相关“键”的数据库。

For a client-server authentication, the client requests from the KDC a "ticket" for access to a specific asset. KDC uses the client's secret and the server's secret to construct the ticket which allows the client and server to mutually authenticate each other, while keeping the secrets hidden.对于客户端-服务器身份验证,客户端向KDC请求访问特定资产的“票证”。KDC使用客户端的秘密和服务器的秘密来构造票证,该票证允许客户端和服务器相互验证,同时隐藏秘密。

For the configuration of MongoDB for Kerberos support, two kinds of principal names are of interest: user principals and service principals.对于MongoDB的Kerberos支持配置,有两种主体名称值得关注:用户主体服务主体

User Principal用户主体

To authenticate using Kerberos, you must add the Kerberos user principals to MongoDB to the $external database. User principal names have the form:要使用Kerberos进行身份验证,您必须将MongoDB的Kerberos用户主体添加到$external数据库中。用户主体名称的格式如下:

<username>@<KERBEROS REALM>

For every user you want to authenticate using Kerberos, you must create a corresponding user in MongoDB in the $external database.对于要使用Kerberos进行身份验证的每个用户,您必须在$external数据库中的MongoDB中创建一个相应的用户。

To use Client Sessions and Causal Consistency Guarantees with $external authentication users (Kerberos, LDAP, or X.509 users), usernames cannot be greater than 10k bytes.要对$external身份验证用户(Kerberos、LDAP或X.509用户)使用客户端会话和因果一致性保证,用户名不能大于10k字节。

For examples of adding a user to MongoDB as well as authenticating as that user, see Configure Self-Managed MongoDB with Kerberos Authentication on Linux and Configure Self-Managed MongoDB with Kerberos Authentication on Windows.有关向MongoDB添加用户以及作为该用户进行身份验证的示例,请参阅在Linux上配置具有Kerberos身份验证的自管理MongoDB在Windows上配置具有Kerberos身份验证的自我管理MongoDB

Tip

Manage Users and Roles on Self-Managed Deployments for general information regarding creating and managing users in MongoDB.在自我管理部署中管理用户和角色,以获取有关在MongoDB中创建和管理用户的一般信息。

Service Principal服务主体

Every MongoDB mongod and mongos instance (or mongod.exe or mongos.exe on Windows) must have an associated service principal. Service principal names have the form:每个MongoDB mongodmongos实例(或Windows上的mongod.exemongos.exe)都必须有一个关联的服务主体。服务主体名称的格式如下:

<service>/<fully qualified domain name>@<KERBEROS REALM>

For MongoDB, the <service> defaults to mongodb. 对于MongoDB,<service>默认为mongodbFor example, if m1.example.com is a MongoDB server, and example.com maintains the EXAMPLE.COM Kerberos realm, then m1 should have the service principal name mongodb/m1.example.com@EXAMPLE.COM.例如,如果m1.example.com是一个MongoDB服务器,并且EXAMPLE.COM维护示例Kerberos领域,那么m1应该具有服务主体名称mongodb/m1.example.com@EXAMPLE.COM

To specify a different value for <service>, use serviceName during the start up of mongod or mongos (or mongod.exe or mongos.exe). mongosh or other clients may also specify a different service principal name using serviceName.

Service principal names must be reachable over the network using the fully qualified domain name (FQDN) part of its service principal name.必须使用服务主体名称的完全限定域名(FQDN)部分通过网络访问服务主体名称。

By default, Kerberos attempts to identify hosts using the /etc/krb5.conf file before using DNS to resolve hosts.默认情况下,Kerberos在使用DNS解析主机之前,会尝试使用/etc/krb5.conf文件识别主机。

On Windows, if running MongoDB as a service, see Assign Service Principal Name to MongoDB Windows Service.在Windows上,如果将MongoDB作为服务运行,请参阅将服务主体名称分配给MongoDB Windows服务

Linux Keytab FilesLinux键盘文件

Linux systems can store Kerberos authentication keys for a service principal in keytab files. Linux系统可以在keytab文件中存储服务主体的Kerberos身份验证键。Each Kerberized mongod and mongos instance running on Linux must have access to a keytab file containing keys for its service principal.在Linux上运行的每个Kerberized mongodmongos实例都必须能够访问一个包含其服务主体键的keytab文件。

To keep keytab files secure, use file permissions that restrict access to only the user that runs the mongod or mongos process.为了确保keytab文件的安全,请使用文件权限,仅允许运行mongodmongos进程的用户访问。

Tickets门票

On Linux, MongoDB clients can use Kerberos's kinit program to initialize a credential cache for authenticating the user principal to servers.在Linux上,MongoDB客户端可以使用Kerberos的kinit程序初始化凭据缓存,以便向服务器验证用户主体。

Windows Active Directory活动目录

Unlike on Linux systems, mongod and mongos instances running on Windows do not require access to keytab files. 与Linux系统不同,在Windows上运行的mongodmongos实例不需要访问keytab文件。Instead, the mongod and mongos instances read their server credentials from a credential store specific to the operating system.相反,mongodmongos实例从特定于操作系统的凭据存储中读取其服务器凭据。

However, from the Windows Active Directory, you can export a keytab file for use on Linux systems. See Ktpass for more information.但是,您可以从Windows 活动目录导出键表文件,以便在Linux系统上使用。有关更多信息,请参阅Ktpass

Authenticate With Kerberos使用Kerberos进行身份验证

To configure MongoDB for Kerberos support and authenticate, see Configure Self-Managed MongoDB with Kerberos Authentication on Linux and Configure Self-Managed MongoDB with Kerberos Authentication on Windows.要配置MongoDB以支持Kerberos并进行身份验证,请参阅在Linux上配置具有Kerberos身份验证的自管理MongoDB在Windows上配置具有Kerberos身份验证的自我管理MongoDB

Operational Considerations操作注意事项

DNS

Each host that runs a mongod or mongos instance must have both A and PTR DNS records to provide forward and reverse lookup.运行mongodmongos实例的每个主机都必须同时具有APTR DNS记录,以提供正向和反向查找。

Without A and PTR DNS records, the host cannot resolve the components of the Kerberos domain or the Key Distribution Center (KDC).没有APTR DNS记录,主机无法解析Kerberos域或键分发中心(KDC)的组件。

System Time Synchronization系统时间同步

To successfully authenticate, the system time for each mongod and mongos instance must be within 5 minutes of the system time of the other hosts in the Kerberos infrastructure.为了成功进行身份验证,每个mongodmongos实例的系统时间必须在Kerberos基础架构中其他主机的系统时间的5分钟以内。

Kerberized MongoDB Environments基于Kerberos的MongoDB环境

Driver Support驱动程序支持

The following MongoDB drivers support Kerberos authentication:以下MongoDB驱动程序支持Kerberos身份验证:

Use with Additional MongoDB Authentication Mechanism与其他MongoDB身份验证机制一起使用

Although MongoDB supports the use of Kerberos authentication with other authentication mechanisms, only add the other mechanisms as necessary. 虽然MongoDB支持将Kerberos身份验证与其他身份验证机制一起使用,但只在必要时添加其他机制。See the Incorporate Additional Authentication Mechanisms section in Configure Self-Managed MongoDB with Kerberos Authentication on Linux and Configure Self-Managed MongoDB with Kerberos Authentication on Windows for details.有关详细信息,请参阅在Linux上配置具有Kerberos身份验证的自管理MongoDB在Windows上配置具有Kerberos身份验证的自主管理MongoDB中的“合并其他身份验证机制部分。

Testing and Verification测试与验证

The mongokerberos program 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. mongokerberos程序提供了一种方便的方法来验证平台与MongoDB一起使用的Kerberos配置,并测试MongoDB客户端的Kerberos身份验证是否按预期工作。See the mongokerberos documentation for more information.有关更多信息,请参阅mongokerberos文档。

mongokerberos is available in MongoDB Enterprise only.仅在MongoDB Enterprise中可用。