Opções de arquivo de configuração

Valores de origem externa

As seguintes diretivas de expansão estão disponíveis:

Para obter a documentação completa, consulte Valores de arquivo de configuração de origem externa.

Diretivas de expansão e --configExpand

Se você estiver utilizando diretivas de expansão no arquivo de configuração, você deverá incluir a opção --configExpand ao iniciar o mongod ou mongos. Por exemplo:

mongod --config /etc/mongod.conf  --configExpand "rest,exec"
mongos --config /etc/mongos.conf  --configExpand "rest,exec"

Se o arquivo de configuração incluir uma diretiva de expansão e você iniciar o mongod / mongos sem especificar esta diretiva na opção --configExpand, a mongod / mongos falhará ao iniciar.

Para obter a documentação completa, consulte Valores de arquivo de configuração de origem externa.

systemLog.component Opções

systemLog:
   component:
      accessControl:
         verbosity: <int>
      command:
         verbosity: <int>
      # COMMENT some component verbosity settings omitted for brevity
      replication:
         verbosity: <int>
         election:
            verbosity: <int>
         heartbeats:
            verbosity: <int>
         initialSync:
            verbosity: <int>
         rollback:
            verbosity: <int>
      storage:
         verbosity: <int>
         journal:
            verbosity: <int>
         recovery:
            verbosity: <int>
      write:
         verbosity: <int>

systemLog.component.accessControl.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de log para componentes relacionados ao controle de acesso. Consulte componentes do ACCESS.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.command.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados a comandos. Consulte COMMAND componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.control.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de controle. Consulte CONTROL componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.ftdc.verbosity

Tipo: inteiro

Padrão: 0

Novo na versão 3.2.

O nível de verbosidade da mensagem de log para componentes relacionados às operações de coleta de dados de diagnóstico. Consulte componentes do FTDC.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.geo.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de log para componentes relacionados às operações de análise geoespacial. Consulte GEO componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.index.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de indexação. Consulte componentes do INDEX.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.network.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de rede. Consulte NETWORK componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.query.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de consulta. Consulte QUERY componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.replication.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à replicação. Consulte REPL componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.replication.election.verbosity

Tipo: inteiro

Padrão: 0

Novidades na versão 4.2.

O nível de verbosidade da mensagem de registro para componentes relacionados à eleição. Consulte ELECTION componentes.

Se o systemLog.component.replication.election.verbosity estiver desmarcado, o nível systemLog.component.replication.verbosity também se aplicará aos componentes da eleição.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.replication.heartbeats.verbosity

Tipo: inteiro

Padrão: 0

Novidade na versão 3.6.

O nível de verbosidade da mensagem de registro para componentes relacionados a batidas cardíacas. Consulte REPL_HB componentes.

Se systemLog.component.replication.heartbeats.verbosity estiver desconfigurado, systemLog.component.replication.verbosity nível também se aplica aos componentes de batimentos cardíacos.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.replication.initialSync.verbosity

Tipo: inteiro

Padrão: 0

Novidades na versão 4.2.

O nível de verbosidade da mensagem de registro para componentes relacionados ao initialSync. Veja os componentes INITSYNC.

Se o systemLog.component.replication.initialSync.verbosity estiver desmarcado, o nível do systemLog.component.replication.verbosity também se aplicará aos componentes do initialSync.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.replication.rollback.verbosity

Tipo: inteiro

Padrão: 0

Novidade na versão 3.6.

O nível de verbosidade da mensagem de registro para componentes relacionados à reversão. Consulte componentes do ROLLBACK.

Se o systemLog.component.replication.rollback.verbosity estiver desmarcado, o nível do systemLog.component.replication.verbosity também se aplicará aos componentes de reversão.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.sharding.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados ao sharding. Consulte SHARDING componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.storage.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados ao armazenamento. Consulte componentes do STORAGE.

Se o systemLog.component.storage.journal.verbosity estiver desmarcado, o nível do systemLog.component.storage.verbosity também se aplicará aos componentes do diário.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.storage.journal.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à diário. Consulte componentes do JOURNAL.

Se o systemLog.component.storage.journal.verbosity estiver desmarcado, os componentes de diário terão o mesmo nível de verbosidade que os componentes de armazenamento pai: ou seja, o nível systemLog.component.storage.verbosity se configurado ou o nível de verbosidade padrão.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.storage.recovery.verbosity

Tipo: inteiro

Padrão: 0

Novidades na versão 4.0.

O nível de verbosidade da mensagem de registro para componentes relacionados à recuperação. Consulte componentes do RECOVERY.

Se o systemLog.component.storage.recovery.verbosity estiver desmarcado, o nível do systemLog.component.storage.verbosity também se aplicará aos componentes de recuperação.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.transaction.verbosity

Tipo: inteiro

Padrão: 0

Novidades na versão 4.0.2.

O nível de verbosidade da mensagem de registro para componentes relacionados à transação. Consulte TXN componentes.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

systemLog.component.write.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de gravação. Consulte componentes do WRITE.

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

net.unixDomainSocket Opções

net:
   unixDomainSocket:
      enabled: <boolean>
      pathPrefix: <string>
      filePermissions: <int>

net.unixDomainSocket.enabled

Tipo: booleano

Padrão: true

Ative ou desative a escuta no soquete de domínio UNIX. net.unixDomainSocket.enabled se aplica somente aos sistemas baseados em Unix.

Quando net.unixDomainSocket.enabled está true, mongos ou mongod escuta no soquete UNIX.

O processo mongos ou mongod sempre escuta no soquete UNIX, a menos que um dos seguintes seja verdadeiro:

• net.unixDomainSocket.enabled é false

• --nounixsocket está definido. A opção da linha de comando tem precedência sobre a configuração do arquivo de configuração.

• net.bindIp não está definido

• net.bindIp não especifica localhost ou seu endereço IP associado

mongos ou mongod instalado a partir do .deb oficial e .rpm os pacotes têm a configuração bind_ip definida como 127.0.0.1 por padrão.

net.unixDomainSocket.pathPrefix

Tipo: string

Padrão: /tmp

O caminho para o soquete UNIX. net.unixDomainSocket.pathPrefix se aplica somente aos sistemas baseados em Unix.

Se essa opção não tiver valor, o processo mongos ou mongod criará um soquete com /tmp como prefixo. O MongoDB cria e escuta em um soquete UNIX, a menos que uma das seguintes afirmações seja verdadeira:

• net.unixDomainSocket.enabled é false

• --nounixsocket está definido

• net.bindIp não está definido

• net.bindIp não especifica localhost ou seu endereço IP associado

net.unixDomainSocket.filePermissions

Tipo: int

Padrão: 0700

Define a permissão para o arquivo de soquete de domínio UNIX.

net.unixDomainSocket.filePermissions aplica-se apenas a sistemas baseados em Unix.

net.http Opções

net.tls Opções

net:
   tls:
      mode: <string>
      certificateKeyFile: <string>
      certificateKeyFilePassword: <string>
      certificateSelector: <string>
      clusterCertificateSelector: <string>
      clusterFile: <string>
      clusterPassword: <string>
      CAFile: <string>
      clusterCAFile: <string>
      CRLFile: <string>
      allowConnectionsWithoutCertificates: <boolean>
      allowInvalidCertificates: <boolean>
      allowInvalidHostnames: <boolean>
      disabledProtocols: <string>
      FIPSMode: <boolean>
      logVersions: <string>

net.tls.mode

Tipo: string

Novidades na versão 4.2.

Ativa o TLS usado para todas as conexões de rede. O argumento para a configuração net.tls.mode pode ser um dos seguintes:

Valor	Descrição
disabled	O servidor não usa TLS.
allowTLS	As conexões entre servidores não usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.
preferTLS	As conexões entre servidores usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.
requireTLS	O servidor usa e aceita apenas conexões criptografadas TLS.

Se --tlsCAFile ou tls.CAFile não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Se estiver usando a autenticação x.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando--tlsCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.certificateKeyFile

Tipo: string

Novo na versão 4.2: O arquivo .pem que contém o certificado e a chave TLS.

Começando com MongoDB 4.0 no macOS ou no Windows, você pode usar a configuração net.tls.certificateSelector para especificar um certificado do armazenamento seguro de certificados do sistema operacional em vez de um arquivo de chave PEM. certificateKeyFile e net.tls.certificateSelector são mutuamente exclusivos. Você só pode especificar uma.

• No Linux/BSD, você deve especificar net.tls.certificateKeyFile quando TLS estiver habilitado.

• No Windows ou macOS, você deve especificar net.tls.certificateKeyFile ou net.tls.certificateSelector quando TLS estiver habilitado.

  Importante

  Para Windows apenas, MongoDB 4.0 e posterior não oferecem suporte a arquivos PEM criptografados. mongod falha ao iniciar se encontrar um arquivo PEM criptografado. Para armazenar e acessar com segurança um certificado para uso com TLS no Windows, use net.tls.certificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.certificateKeyFilePassword

Tipo: string

Novidades na versão 4.2: a senha para descriptografar o arquivo de chave de certificado (ou seja, certificateKeyFile). Use a opção net.tls.certificateKeyFilePassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, o mongos ou mongod edita a senha de todos os resultados de geração de registros e relatórios.

A partir do MongoDB 4.0:

• No Linux/BSD, se a chave privada no arquivo PEM estiver criptografada e você não especificar a opção net.tls.certificateKeyFilePassword , o MongoDB solicitará uma senha.

  Para obter mais informações, consulte Senha do Certificado TLS/SSL.

• No macOS, se a chave privada no arquivo PEM estiver criptografada, você deverá especificar explicitamente a opção net.tls.certificateKeyFilePassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte net.tls.certificateSelector) em vez de um arquivo de chave PEM ou usar um arquivo PEM não criptografado.

• No Windows, o MongoDB não oferece suporte a certificados criptografados. O mongod falhará se encontrar um arquivo PEM criptografado. Em vez disso, use net.tls.certificateSelector .

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.certificateSelector

Tipo: string

Novo na versão 4.2: Disponível no Windows e macOS como alternativa ao net.tls.certificateKeyFile. No MongoDB 4.0, consulte net.ssl.certificateSelector.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para usar para TLS/SSL.

net.tls.certificateKeyFile e net.tls.certificateSelector são opções mutuamente exclusivas. Você só pode especificar uma.

net.tls.certificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

Ao usar o armazenamento de certificados SSL do sistema, o OCSP (Online Certificate Status Protocol) é usado para validar o status de revogação dos certificados.

O mongod pesquisa no armazenamento de certificados seguro do sistema operacional os certificados CA necessários para validar a sequência completa de certificados do certificado TLS especificado. Especificamente, o armazenamento de certificados seguro deve conter a CA raiz e quaisquer certificados de CA intermediários necessários para construir a sequência completa de certificados para o certificado TLS.

Aviso

Se você usar net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não recomendamos o uso net.tls.CAFile ou net.tls.clusterFile para especificar o certificado de CA raiz e intermediário

Por exemplo, se o certificado TLS tiver sido assinado com um único certificado CA raiz, o armazenamento de certificados seguro deverá conter esse certificado CA raiz. Se o certificado TLS foi assinado com um certificado CA intermediário, o armazenamento de certificados seguro deverá conter o certificado CA intermediário e o certificado CA raiz.

Observação

Você não pode usar o comando rotateCertificates ou o método shell db.rotateCertificates() ao usar net.tls.certificateSelector ou --tlsCertificateSelector definido como thumbprint

net.tls.clusterCertificateSelector

Tipo: string

Novidade na versão 4.2: disponível no Windows e macOS como alternativa ao net.tls.clusterFile.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento seguro de certificados do sistema operacional para usar para autenticação de assinatura x.509 interna.

net.tls.clusterFile e net.tls.clusterCertificateSelector são opções mutuamente exclusivas. Você só pode especificar uma.

net.tls.clusterCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

O mongod pesquisa no armazenamento de certificados seguro do sistema operacional os certificados CA necessários para validar a cadeia completa de certificados do certificado de cluster especificado. Especificamente, o armazenamento de certificados seguro deve conter a CA raiz e quaisquer certificados de CA intermediários necessários para construir a sequência completa de certificados para o certificado de cluster.

Aviso

Se você usar net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não recomendamos o uso net.tls.CAFile ou net.tls.clusterCAFile para especificar o certificado CA raiz e intermediário.

Por exemplo, se o certificado de cluster tiver sido assinado com um único certificado CA raiz, o armazenamento de certificados seguro deverá conter esse certificado CA raiz. Se o certificado de cluster foi assinado com um certificado CA intermediário, o armazenamento de certificados seguro deverá conter o certificado CA intermediário e o certificado CA raiz.

mongod / mongos registra um aviso na conexão se o x for apresentado. O certificado 509 expira dentro 30 dias a partir da hora do sistema host mongod/mongos . Consulte x.509 trigger de certificados próximos da expiração para obter mais informações.

net.tls.clusterFile

Tipo: string

Novo na versão 4.2: O arquivo .pem que contém o arquivo de chave de certificado x.509 para autenticação de associação para o cluster ou conjunto de réplicas.

Começando com MongoDB 4.0 no macOS ou no Windows, você pode usar a opção net.tls.clusterCertificateSelector para especificar um certificado do armazenamento seguro de certificados do sistema operacional em vez de um arquivo de chave PEM. As opções do net.tls.clusterFile e net.tls.clusterCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

Se o net.tls.clusterFile não especificar o arquivo .pem para autenticação de cluster interno ou a alternativa net.tls.clusterCertificateSelector, o cluster usará o arquivo .pem especificado na configuração certificateKeyFile ou o certificado retornado pelo net.tls.certificateSelector.

Se estiver usando a autenticação x.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando--tlsCertificateSelector.

mongod / mongos registra um aviso na conexão se o x for apresentado. O certificado 509 expira dentro 30 dias a partir da hora do sistema host mongod/mongos . Consulte x.509 trigger de certificados próximos da expiração para obter mais informações.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

Importante

Para Windows apenas, MongoDB 4.0 e posterior não oferecem suporte a arquivos PEM criptografados. mongod falha ao iniciar se encontrar um arquivo PEM criptografado. Para armazenar e acessar com segurança um certificado para uso com autenticação de associação no Windows, use net.tls.clusterCertificateSelector.

net.tls.clusterPassword

Tipo: string

Novidades na versão 4.2: a senha para descriptografar o x.509 arquivo de chave de certificado especificado com --sslClusterFile. Use a opção net.tls.clusterPassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, mongos ou mongod edita a senha de todos os resultados de geração de registros e relatórios.

A partir do MongoDB 4.0:

• No Linux/BSD, se a chave privada no x.509 estiver criptografado e você não especificar a opção net.tls.clusterPassword , o MongoDB solicitará uma senha.

  Para obter mais informações, consulte Senha do Certificado TLS/SSL.

• No macOS, se a chave privada no x.509 estiver criptografado, você deve especificar explicitamente a opção net.tls.clusterPassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte net.tls.clusterCertificateSelector) em vez de um arquivo PEM de cluster ou usar um arquivo PEM não criptografado.

• No Windows, o MongoDB não oferece suporte a certificados criptografados. O mongod falhará se encontrar um arquivo PEM criptografado. Utilize net.tls.clusterCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.CAFile

Tipo: string

Novo na versão 4.2: O arquivo .pem que contém a cadeia de certificados raiz da Autoridade de Certificação. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Somente Windows/macOS

Se estiver utilizando net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não utilize net.tls.CAFile para especificar os certificados CA raiz e intermediário. Armazene todos os certificados CA necessários para validar toda a cadeia de confiança dos certificados net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector no armazenamento seguro de certificados.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.clusterCAFile

Tipo: string

Novo na versão 4.2: o arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação usada para validar o certificado apresentado por um cliente que estabelece uma conexão. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos. net.tls.clusterCAFile requer que net.tls.CAFile esteja definido.

Se net.tls.clusterCAFile não especificar o arquivo .pem para validar o certificado de um cliente estabelecendo uma conexão, o cluster utilizará o arquivo .pem especificado na opção net.tls.CAFile .

net.tls.clusterCAFile permite que você use autoridades de certificação separadas para verificar as partes cliente-servidor e servidor-cliente do handshake TLS.

A partir de 4.0, no macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte net.tls.clusterCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o net.tls.clusterCAFile.

Somente Windows/macOS

Se estiver utilizando net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não utilize net.tls.clusterCAFile para especificar os certificados CA raiz e intermediário. Armazene todos os certificados CA necessários para validar toda a cadeia de confiança dos certificados net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector no armazenamento seguro de certificados.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.CRLFile

Tipo: string

Novidade na versão 4.2: No MongoDB 4.0 e anteriores, consulte net.ssl.CRLFile.

O arquivo .pem que contém a lista de revogação de certificado. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Observação

• A partir do MongoDB 4.0, você não pode especificar net.tls.CRLFile no macOS. Em vez disso, você pode usar o armazenamento de certificados SSL do sistema, que usa OCSP (Online Certificate Status Protocol) para validar o status de revogação dos certificados. Consulte net.ssl.certificateSelector em MongoDB 4.0 e net.tls.certificateSelector no MongoDB 4.2+ para usar o armazenamento de certificados SSL do sistema.

• Para verificar a revogação de certificados, o MongoDB enables o uso do OCSP (Online Certificate Status Protocol) por padrão como uma alternativa à especificação de um arquivo CRL ou ao uso do armazenamento de certificados SSL do sistema.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.allowConnectionsWithoutCertificates

Tipo: booleano

Novidades na versão 4.2.

Por padrão, o servidor ignora a validação do certificado de cliente, a menos que o servidor esteja configurado para utilizar um arquivo CA. Se um arquivo CA for fornecido, as regras a seguir serão aplicadas:

• Para clientes que não fornecem certificados, mongod ou mongos criptografa a conexão TLS/SSL, supondo que a conexão seja bem-sucedida.

• Para clientes que apresentam um certificado, o mongos ou mongod executa a validação do certificado utilizando a cadeia de certificado raiz especificada pelo CAFile e rejeita clientes com certificados inválidos.

Use a opção net.tls.allowConnectionsWithoutCertificates se você tiver uma implantação mista que inclua clientes que não apresentam ou não podem apresentar certificados para o mongos ou mongod.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.allowInvalidCertificates

Tipo: booleano

Novidades na versão 4.2.

Habilite ou desabilite as verificações de validação de certificados TLS em outros servidores no cluster e permita o uso de certificados inválidos para conexão.

Observação

Se você especificar --tlsAllowInvalidCertificates ou tls.allowInvalidCertificates: true ao usar a autenticação x.509, um certificado inválido será suficiente apenas para estabelecer uma conexão TLS, mas será insuficiente para autenticação.

Ao usar a configuração net.tls.allowInvalidCertificates, o MongoDB registra um aviso sobre o uso do certificado inválido.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar mongod e mongos para TLS/SSL e autenticação interna/associação.

net.tls.allowInvalidHostnames

Tipo: booleano

Padrão: false

Quando o net.tls.allowInvalidHostnames é true, o MongoDB desabilita a validação dos nomes de host em certificados TLS. Isso permite ao mongod ou mongos se conectar a outras instâncias MongoDB no agrupamento, mesmo se o nome de host de seus certificados não corresponder ao nome de host especificado.

Para mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL.

net.tls.disabledProtocols

Tipo: string

Impede que um servidor MongoDB em execução com TLS aceite conexões recebidas que usam um protocolo ou protocolos específicos. Para especificar vários protocolos, use uma lista separada por vírgula de protocolos, mas não use espaços após as vírgulas. Se você incluir um espaço antes do nome de um protocolo, o servidor o interpretará como um protocolo não reconhecido e não iniciará.

net.tls.disabledProtocols reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e TLS1_3.

• No macOS, você não pode desativar TLS1_1 e deixar TLS1_0 e TLS1_2 ativados. Você deve desativar pelo menos um dos outros dois, por exemplo, TLS1_0,TLS1_1.

• Para listar vários protocolos, especifique como uma lista separada por vírgula de protocolos sem espaços após as vírgulas. Por exemplo TLS1_0,TLS1_1.

• Especificar um protocolo não reconhecido ou incluir um espaço após uma vírgula impede que o servidor seja iniciado.

• Os protocolos desabilitados especificados substituem qualquer protocolo padrão desabilitado.

O MongoDB desabilita o uso do TLS 1.0 se TLS 1.1+ está disponível no sistema. Para habilitar o TLS 1.0, especifique none para net.tls.disabledProtocols.

Os membros dos conjuntos de réplicas e cluster fragmentado devem falar pelo menos um protocolo em comum.

Dica

Veja também:

Não permitir protocolos

net.tls.FIPSMode

Tipo: booleano

Novidades na versão 4.2.

Ative ou desative o uso do modo FIPS da biblioteca TLS para o mongos ou mongod. Seu sistema deve ter uma biblioteca compatível com FIPS para usar a opção net.tls.FIPSMode .

Observação

O TLS/SSL compatível com FIPS está disponível apenas no MongoDB Enterprise. Consulte Configurar MongoDB para FIPS para obter mais informações.

net.tls.logVersions

Tipo: string

Instrui mongos ou mongod a registrar uma mensagem quando um cliente se conecta usando uma versão especificada do TLS.

Especifique uma única versão do TLS ou uma lista separada por vírgula de várias versões do TLS.

Exemplo

Para instruir mongos ou mongod a registrar uma mensagem quando um cliente se conectar usando TLS 1.2 ou TLS 1.3, defina net.tls.logVersions como "TLS1_2,TLS1_3".

net.ssl Opções

net:
   ssl:                            # deprecated since 4.2
      sslOnNormalPorts: <boolean>  # deprecated since 2.6
      mode: <string>
      PEMKeyFile: <string>
      PEMKeyPassword: <string>
      certificateSelector: <string>
      clusterCertificateSelector: <string>
      clusterFile: <string>
      clusterPassword: <string>
      CAFile: <string>
      clusterCAFile: <string>
      CRLFile: <string>
      allowConnectionsWithoutCertificates: <boolean>
      allowInvalidCertificates: <boolean>
      allowInvalidHostnames: <boolean>
      disabledProtocols: <string>
      FIPSMode: <boolean>

net.ssl.sslOnNormalPorts

Tipo: booleano

Descontinuado desde a versão 2.6: Em vez disso, use net.tls.mode: requireTLS.

Ative ou desative TLS/SSL para mongos ou mongod.

Com o net.ssl.sslOnNormalPorts, um mongos ou mongod exige criptografia TLS/SSL para todas as conexões na porta MongoDB padrão ou a porta especificada por net.port. Por padrão, net.ssl.sslOnNormalPorts está desabilitado.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.mode

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.mode.

Habilita TLS/SSL ou TLS/SSL misto usado para todas as conexões de rede. O argumento para a configuração net.ssl.mode pode ser um dos seguintes:

Valor	Descrição
disabled	O servidor não usa TLS/SSL.
allowSSL	As conexões entre servidores não usam TLS/SSL. Para conexões recebidas, o servidor aceita TLS/SSL e não TLS/não SSL.
preferSSL	As conexões entre servidores usam TLS/SSL. Para conexões recebidas, o servidor aceita TLS/SSL e não TLS/não SSL.
requireSSL	O servidor usa e aceita apenas conexões criptografadas TLS/SSL.

Se --tlsCAFile/net.tls.CAFile (ou seus aliases --sslCAFile/net.ssl.CAFile) não for especificado e você não estiver usando a autenticação x.509, você deve definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados de CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Para usar a autenticação x.509, --tlsCAFile ou net.tls.CAFile deve-se especificar a menos que você esteja usando --tlsCertificateSelector ou --net.tls.certificateSelector.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.PEMKeyFile

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.certificateKeyFile.

O arquivo .pem que contém o certificado e a chave TLS/SSL.

Começando com MongoDB 4.0 no macOS ou no Windows, você pode usar a configuração net.ssl.certificateSelector para especificar um certificado do armazenamento seguro de certificados do sistema operacional em vez de um arquivo de chave PEM. PEMKeyFile e net.ssl.certificateSelector são mutuamente exclusivos. Você só pode especificar uma.

• No Linux/BSD, você deve especificar net.ssl.PEMKeyFile quando TLS/SSL estiver habilitado.

• No Windows ou macOS, você deve especificar net.ssl.PEMKeyFile ou net.ssl.certificateSelector quando TLS/SSL estiver habilitado.

  Importante

  Para Windows apenas, MongoDB 4.0 e posterior não oferecem suporte a arquivos PEM criptografados. mongod falha ao iniciar se encontrar um arquivo PEM criptografado. Para armazenar e acessar com segurança um certificado para uso com TLS/SSL no Windows, use net.ssl.certificateSelector.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.PEMKeyPassword

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.certificateKeyFilePassword.

A senha para descriptografar o arquivo da chave de certificado (ou seja, PEMKeyFile). Use a opção net.ssl.PEMKeyPassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, o mongos ou mongod edita a senha de todos os resultados de geração de registros e relatórios.

A partir do MongoDB 4.0:

• No Linux/BSD, se a chave privada no arquivo PEM estiver criptografada e você não especificar a opção net.ssl.PEMKeyPassword , o MongoDB solicitará uma senha.

  Para obter mais informações, consulte Senha do Certificado TLS/SSL.

• No macOS, se a chave privada no arquivo PEM estiver criptografada, você deverá especificar explicitamente a opção net.ssl.PEMKeyPassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte net.ssl.certificateSelector) em vez de um arquivo de chave PEM ou usar um arquivo PEM não criptografado.

• No Windows, o MongoDB não oferece suporte a certificados criptografados. O mongod falhará se encontrar um arquivo PEM criptografado. Em vez disso, use net.ssl.certificateSelector .

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.certificateSelector

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.certificateSelector.

Novo na versão 4.0: Disponível no Windows e macOS como alternativa ao net.ssl.PEMKeyFile.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para usar para TLS/SSL.

net.ssl.PEMKeyFile e net.ssl.certificateSelector são opções mutuamente exclusivas. Você só pode especificar uma.

net.ssl.certificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

Ao usar o armazenamento de certificados SSL do sistema, o OCSP (Online Certificate Status Protocol) é usado para validar o status de revogação dos certificados.

O mongod pesquisa no armazenamento de certificados seguro do sistema operacional os certificados CA necessários para validar a cadeia completa de certificados do certificado TLS/SSL especificado. Especificamente, o armazenamento de certificados seguro deve conter a CA raiz e quaisquer certificados de CA intermediários necessários para construir a cadeia completa de certificados para o certificado TLS/SSL. Não use net.ssl.CAFile ou net.ssl.clusterFile para especificar o certificado de CA raiz e intermediário

Por exemplo, se o certificado TLS/SSL foi assinado com um único certificado CA raiz, o armazenamento de certificados seguro deverá conter esse certificado CA raiz. Se o certificado TLS/SSL foi assinado com um certificado CA intermediário, o armazenamento de certificados seguro deverá conter o certificado CA intermediário e o certificado CA raiz.

net.ssl.clusterCertificateSelector

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.clusterCertificateSelector.

Novo na versão 4.0: Disponível no Windows e macOS como alternativa ao net.ssl.clusterFile.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento seguro de certificados do sistema operacional para usar para autenticação de assinatura x.509 interna.

net.ssl.clusterFile e net.ssl.clusterCertificateSelector são opções mutuamente exclusivas. Você só pode especificar uma.

net.ssl.clusterCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

O mongod pesquisa no armazenamento de certificados seguro do sistema operacional os certificados CA necessários para validar a cadeia completa de certificados do certificado de cluster especificado. Especificamente, o armazenamento de certificados seguro deve conter a CA raiz e quaisquer certificados de CA intermediários necessários para construir a sequência completa de certificados para o certificado de cluster. Não use net.ssl.CAFile ou net.ssl.clusterFile para especificar o certificado de CA raiz e intermediário.

Por exemplo, se o certificado de cluster tiver sido assinado com um único certificado CA raiz, o armazenamento de certificados seguro deverá conter esse certificado CA raiz. Se o certificado de cluster foi assinado com um certificado CA intermediário, o armazenamento de certificados seguro deverá conter o certificado CA intermediário e o certificado CA raiz.

net.ssl.clusterFile

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.clusterFile.

O arquivo .pem que contém o arquivo de chave de certificado x.509 para autenticação de associação para o cluster ou conjunto de réplicas.

Começando com MongoDB 4.0 no macOS ou no Windows, você pode usar a opção net.ssl.clusterCertificateSelector para especificar um certificado do armazenamento seguro de certificados do sistema operacional em vez de um arquivo de chave PEM. As opções do net.ssl.clusterFile e net.ssl.clusterCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

Se o net.ssl.clusterFile não especificar o arquivo .pem para autenticação de cluster interno ou a alternativa net.ssl.clusterCertificateSelector, o cluster usará o arquivo .pem especificado na configuração PEMKeyFile ou o certificado retornado pelo net.ssl.certificateSelector.

Para usar a autenticação x.509, --tlsCAFile ou net.tls.CAFile deve-se especificar a menos que você esteja usando --tlsCertificateSelector ou --net.tls.certificateSelector.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

Importante

Para Windows apenas, MongoDB 4.0 e posterior não oferecem suporte a arquivos PEM criptografados. mongod falha ao iniciar se encontrar um arquivo PEM criptografado. Para armazenar e acessar com segurança um certificado para uso com autenticação de associação no Windows, use net.ssl.clusterCertificateSelector.

net.ssl.clusterPassword

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.clusterPassword.

A senha para descriptografar o x.509 arquivo de chave de certificado especificado com --sslClusterFile. Use a opção net.ssl.clusterPassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, o mongos ou mongod edita a senha de todos os resultados de geração de registros e relatórios.

A partir do MongoDB 4.0:

• No Linux/BSD, se a chave privada no x.509 estiver criptografado e você não especificar a opção net.ssl.clusterPassword , o MongoDB solicitará uma senha.

  Para obter mais informações, consulte Senha do Certificado TLS/SSL.

• No macOS, se a chave privada no x.509 estiver criptografado, você deve especificar explicitamente a opção net.ssl.clusterPassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte net.ssl.clusterCertificateSelector) em vez de um arquivo PEM de cluster ou usar um arquivo PEM não criptografado.

• No Windows, o MongoDB não oferece suporte a certificados criptografados. O mongod falhará se encontrar um arquivo PEM criptografado. Utilize net.ssl.clusterCertificateSelector.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.CAFile

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.CAFile.

O arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Somente Windows/macOS

Se estiver utilizando net.ssl.certificateSelector e/ou net.ssl.clusterCertificateSelector, não utilize net.ssl.CAFile para especificar os certificados CA raiz e intermediário. Armazene todos os certificados CA necessários para validar toda a cadeia de confiança dos certificados net.ssl.certificateSelector e/ou net.ssl.clusterCertificateSelector no armazenamento seguro de certificados.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.clusterCAFile

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.clusterCAFile.

O arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação usada para validar o certificado apresentado por um cliente que estabelece uma conexão. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos. net.ssl.clusterCAFile requer que net.ssl.CAFile esteja definido.

Se net.ssl.clusterCAFile não especificar o arquivo .pem para validar o certificado de um cliente estabelecendo uma conexão, o cluster utilizará o arquivo .pem especificado na opção net.ssl.CAFile .

net.ssl.clusterCAFile permite que você use autoridades de certificação separadas para verificar as partes cliente-servidor e servidor-cliente do handshake TLS.

A partir de 4.0, no macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte net.ssl.clusterCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o net.ssl.clusterCAFile.

Somente Windows/macOS

Se estiver utilizando net.ssl.certificateSelector e/ou net.ssl.clusterCertificateSelector, não utilize net.ssl.clusterCAFile para especificar os certificados CA raiz e intermediário. Armazene todos os certificados CA necessários para validar toda a cadeia de confiança dos certificados net.ssl.certificateSelector e/ou net.ssl.clusterCertificateSelector no armazenamento seguro de certificados.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.CRLFile

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.CRLFile.

O arquivo .pem que contém a lista de revogação de certificado. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Observação

• A partir do MongoDB 4.0, você não pode especificar net.ssl.CRLFile no macOS. Em vez disso, você pode usar o armazenamento de certificados SSL do sistema, que usa OCSP (Online Certificate Status Protocol) para validar o status de revogação dos certificados. Consulte net.ssl.certificateSelector em MongoDB 4.0 e net.tls.certificateSelector no MongoDB 4.2 para usar o armazenamento de certificados SSL do sistema.

• O MongoDB permite, por padrão, o uso do OCSP (Online Certificate Status Protocol) para verificar a revogação do certificado como uma alternativa à especificação de um arquivo CRL ou ao uso do armazenamento de certificados SSL do sistema.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.allowConnectionsWithoutCertificates

Tipo: booleano

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.allowConnectionsWithoutCertificates.

Para clientes que não fornecem certificados, mongod ou mongos criptografa a conexão TLS/SSL, supondo que a conexão seja bem-sucedida.

Para clientes que apresentam um certificado, no entanto, o mongos ou mongod executa a validação do certificado utilizando a cadeia de certificado raiz especificada pelo CAFile e rejeita clientes com certificados inválidos.

Use a opção net.ssl.allowConnectionsWithoutCertificates se você tiver uma implantação mista que inclua clientes que não apresentam ou não podem apresentar certificados para o mongos ou mongod.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.allowInvalidCertificates

Tipo: booleano

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.allowInvalidCertificates.

Habilite ou desabilite as verificações de validação de certificados TLS/SSL em outros servidores no cluster e permite o uso de certificados inválidos para conexão.

Observação

A partir do MongoDB 4,0, se você especificar qualquer uma das seguintes opções de autenticação x.509, um certificado inválido será suficiente apenas para estabelecer uma conexão TLS, mas será insuficiente para autenticação:

• --sslAllowInvalidCertificates ou net.ssl.allowInvalidCertificates: true para MongoDB 4.0 e versões mais recentes

• --tlsAllowInvalidCertificates ou net.tls.allowInvalidCertificates: true para MongoDB 4.2 e versões mais recentes

Ao usar a configuração net.ssl.allowInvalidCertificates , o MongoDB registra um aviso sobre o uso de um certificado inválido.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.allowInvalidHostnames

Tipo: booleano

Padrão: false

Descontinuado desde a versão 4.2.

Em vez disso, use net.tls.allowInvalidHostnames .

Quando net.ssl.allowInvalidHostnames é true, o MongoDB desativa a validação dos nomes de host nos certificados TLS/SSL, permitindo que mongod se conecte às instâncias do MongoDB se o nome de host dos certificados não corresponder ao nome de host especificado.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

net.ssl.disabledProtocols

Tipo: string

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.disabledProtocols.

Impede que um servidor MongoDB em execução com TLS/SSL aceite conexões recebidas que usam um ou mais protocolos específicos. Para especificar protocolos, use uma lista de protocolos separados por vírgulas.

net.ssl.disabledProtocols reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e a partir da versão 4.0.4 (e 3.6.9), TLS1_3.

• No macOS, você não pode desativar TLS1_1 e deixar TLS1_0 e TLS1_2 ativados. Você deve desativar pelo menos um dos outros dois, por exemplo, TLS1_0,TLS1_1.

• Para listar vários protocolos, especifique uma lista de protocolos separados por vírgula. Por exemplo TLS1_0,TLS1_1.

• A especificação de um protocolo não reconhecido impede o servidor de iniciar.

• Os protocolos desabilitados especificados substituem qualquer protocolo padrão desabilitado.

A partir da versão 4.0, o MongoDB desabilita o uso do TLS 1.0 se TLS 1.1+ está disponível no sistema. Para habilitar o TLS desabilitado 1.0, especifique none a net.ssl.disabledProtocols.

Os membros dos conjuntos de réplicas e cluster fragmentado devem falar pelo menos um protocolo em comum.

Dica

Veja também:

Não permitir protocolos

net.ssl.FIPSMode

Tipo: booleano

Descontinuado desde a versão 4.2: em vez disso, usenet.tls.FIPSMode.

Habilite ou desabilite o uso do modo FIPS da biblioteca TLS/SSL para o mongos ou mongod. Seu sistema deve ter uma biblioteca compatível com FIPS para usar a opção net.ssl.FIPSMode .

Observação

O TLS/SSL compatível com FIPS está disponível apenas no MongoDB Enterprise. Consulte Configurar MongoDB para FIPS para obter mais informações.

net.compression Opção

net:
   compression:
      compressors: <string>

net.compression.compressors

Padrão: snappy,zstd,zlib

Novidade na versão 3.4.

Especifica os compressores padrão a serem usados na comunicação entre essa instância mongod ou mongos e:

• outros membros do sistema se a instância fizer parte de um conjunto de réplicas ou de um cluster fragmentado

• mongosh

• drivers que suportam o formato de mensagem OP_COMPRESSED .

MongoDB é compatível com os seguintes compactadores:

• snappy

• zlib (Disponível a partir do MongoDB 3.6)

• zstd (Disponível a partir do MongoDB 4.2)

Nas versões 3.6 e 4.0, mongod e mongos ativam a compactação de rede por padrão com snappy como o compressor.

A partir da versão 4.2, as instânciasmongod e mongos padrão para ambos os compressores snappy,zstd,zlib, nessa ordem.

Para desativar a compactação de rede, defina o valor como disabled.

Importante

As mensagens são compactadas quando ambas as partes habilitam a compactação de rede. Caso contrário, as mensagens entre as partes serão descompactadas.

Se você especificar vários compressores, a ordem na qual você lista os compressores importam, bem como o iniciador de comunicação. Por exemplo, se o mongosh especificar os seguintes compressores de rede zlib,snappy e o mongod especificar snappy,zlib, as mensagens entre mongosh e mongod utilizarão zlib.

Se as partes não compartilharem pelo menos um compressor comum, as mensagens entre as partes serão descompactadas. Por exemplo, se mongosh especificar o compressor de rede zlib e mongod especificar snappy, as mensagens entre mongosh e mongod não serão compactadas.

Opções de configuração de gerenciamento de chaves

security:
   enableEncryption: <boolean>
   encryptionCipherMode: <string>
   encryptionKeyFile: <string>
   kmip:
      keyIdentifier: <string>
      rotateMasterKey: <boolean>
      serverName: <string>
      port: <string>
      clientCertificateFile: <string>
      clientCertificatePassword: <string>
      clientCertificateSelector: <string>
      serverCAFile: <string>
      connectRetries: <int>
      connectTimeoutMS: <int>

security.enableEncryption

Tipo: booleano

Padrão: false

Novidades na versão 3.2: ativa a criptografia para o storage engine WiredTiger. Você deve definir como true para passar chave de criptografia e configurações.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.encryptionCipherMode

Tipo: string

Padrão: AES256-CBC

Novo na versão 3.2.

O modo de cifra a ser usado para encryption at rest:

Modo	Descrição
AES256-CBC	Padrão de criptografia avançada de 256 bits no modo de sequenciamento de blocos de cifra
AES256-GCM	Padrão de criptografia avançada de 256 bits no modo Galois/Counter Disponível apenas no Linux. Alterado na versão 4,0: MongoDB Enterprise no Windows não suporta mais AES256-GCM como uma cifra de bloco para criptografia em repouso. Esse uso é compatível apenas com Linux.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.encryptionKeyFile

Tipo: string

O caminho para o arquivo-chave local ao gerenciar chaves por um processo diferente do KMIP. Definido apenas ao gerenciar chaves por um processo diferente do KMIP. Se os dados já estiverem criptografados usando KMIP, o MongoDB gerará um erro.

Requer que security.enableEncryption seja true.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.keyIdentifier

Tipo: string

Novo na versão 3.2.

Identificador KMIP exclusivo para uma chave existente no servidor KMIP. Inclua para usar a chave associada ao identificador como chave do sistema. Você só pode usar a configuração na primeira vez em que ativar a criptografia para a instância mongod . Exige que security.enableEncryption seja verdadeiro.

Se não for especificada, o MongoDB solicita que o servidor KMIP crie uma chave nova para utilizar como chave do sistema.

Se o servidor KMIP não conseguir localizar uma chave com o identificador especificado ou os dados já estiverem criptografados com uma chave, o MongoDB lançará um erro.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.rotateMasterKey

Tipo: booleano

Padrão: false

Novo na versão 3.2.

Se for verdade, gire a chave mestra e criptografe novamente o keystore interno.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

Dica

Veja também:

Rotação da chave mestra KMIP

security.kmip.serverName

Tipo: string

Novo na versão 3.2.

Nome do host ou endereço IP do servidor KMIP ao qual se conectar. Exige que security.enableEncryption seja verdadeiro.

A partir do MongoDB 4.2.1 (e 4.0.14), você pode especificar vários servidores KMIP como uma lista separada por vírgula, por exemplo server1.example.com,server2.example.com. Na inicialização, o mongod tenta estabelecer uma conexão com cada servidor na ordem listada e seleciona o primeiro servidor com o qual pode estabelecer uma conexão com êxito. A seleção do servidor KMIP ocorre apenas na inicialização.

Ao se conectar a um servidor KMIP, mongod verifica se o security.kmip.serverName especificado corresponde ao nome alternativo do assunto SAN (ou, se SAN não estiver presente, o nome comum CN) no certificado apresentado pelo Servidor KMIP. Se SAN estiver presente, mongod não corresponde a CN. Se o nome do host não corresponder a SAN (ou CN), o mongod não conseguirá se conectar.

A partir do MongoDB 4.2, ao realizar a comparação de SAN, o MongoDB oferece suporte à comparação de nomes DNS ou endereços IP. Nas versões anteriores, o MongoDB suporta apenas comparações de nomes DNS.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.port

Tipo: string

Padrão: 5696

Novo na versão 3.2.

Número da porta a ser usada para comunicação com o servidor KMIP. Exige security.kmip.serverName. Requer que security.enableEncryption seja verdadeiro.

Se especificar vários servidores KMIP com security.kmip.serverName, o mongod utilizará a porta especificada com security.kmip.port para todos os servidores KMIP fornecidos.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.clientCertificateFile

Tipo: string

Caminho para o arquivo .pem usado para autenticar o MongoDB no servidor KMIP. O arquivo .pem especificado deve conter o certificado e a chave TLS/SSL.

Para utilizar esta configuração, você também deve especificar a configuração do security.kmip.serverName .

Observação

A partir de 4.0, no macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte security.kmip.clientCertificateSelector.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.clientCertificatePassword

Tipo: string

Novo na versão 3.2.

A senha para descriptografar o certificado do cliente (ou seja, security.kmip.clientCertificateFile), usado para autenticar o MongoDB no servidor KMIP. Use a opção somente se o certificado estiver criptografado.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.clientCertificateSelector

Tipo: string

Novidades na versão 4.0: (e 5.0)

Disponível no Windows e macOS como uma alternativa ao security.kmip.clientCertificateFile.

security.kmip.clientCertificateFile e security.kmip.clientCertificateSelector são opções mutuamente exclusivas. Você só pode especificar uma.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para autenticar o MongoDB no servidor KMIP.

security.kmip.clientCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.serverCAFile

Tipo: string

Novo na versão 3.2.

Caminho para o arquivo CA. Usado para validar a conexão segura do cliente com o servidor KMIP.

Observação

A partir de 4.0, no macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte security.kmip.clientCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o security.kmip.serverCAFile.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.connectRetries

Tipo: int

Padrão: 0

Quantas vezes tentar novamente a conexão inicial com o servidor KMIP. Use junto com connectTimeoutMS para controlar quanto tempo o mongod espera por uma resposta entre cada nova tentativa.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.connectTimeoutMS

Tipo: int

Padrão: 5000

Tempo limite em milissegundos para aguardar uma resposta do servidor KMIP. Se a configuração connectRetries for especificada, o mongod aguardará até o valor especificado com connectTimeoutMS para cada nova tentativa.

O valor deve ser 1000 ou superior.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.sasl Opções

security:
   sasl:
      hostName: <string>
      serviceName: <string>
      saslauthdSocketPath: <string>

security.sasl.hostName

Tipo: string

Um nome de domínio de servidor totalmente qualificado com a finalidade de configurar a autenticação SASL e Kerbero. O nome de host do SASL substitui o nome de host somente para a configuração do SASL e Kerberos.

security.sasl.serviceName

Tipo: string

Nome registrado do serviço usando SASL. Essa opção permite que você substitua o componente de nome de serviço Kerberos padrão do nome principal do Kerberos, por instância. Se não especificado, o valor padrão é mongodb.

O MongoDB permite definir essa opção somente na inicialização. O setParameter não pode alterar essa configuração.

Esta opção está disponível apenas no MongoDB Enterprise.

Importante

Verifique se o seu driver suporta nomes de serviço alternativos. Para mongosh e outras ferramentas MongoDB para se conectar ao novo serviceName, consulte a opção gssapiServiceName .

security.sasl.saslauthdSocketPath

Tipo: string

O caminho para o arquivo de soquete do domínio UNIX para saslauthd.

security.ldap Opções

security:
   ldap:
      servers: <string>
      bind:
         method: <string>
         saslMechanisms: <string>
         queryUser: <string>
         queryPassword: <string | array>
         useOSDefaults: <boolean>
      transportSecurity: <string>
      timeoutMS: <int>
      userToDNMapping: <string>
      authz:
         queryTemplate: <string>
      validateLDAPServerConfig: <boolean>

security.ldap.servers

Tipo: string

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

O servidor LDAP no qual o mongod ou mongos autentica os usuários ou determina quais ações um usuário está autorizado a executar em um determinado banco de dados. Se o servidor LDAP especificado tiver quaisquer instâncias replicadas, você poderá especificar o host e a porta de cada servidor replicado em uma lista delimitada por vírgula.

Se sua infraestrutura LDAP dividir o diretório LDAP em vários servidores LDAP, especifique um servidor LDAP ou qualquer uma de suas instâncias replicadas no . O MongoDB suporta as security.ldap.servers seguintes referências LDAP, conforme definido em RFC . .4511 4110. Não utilize o para listar todos os servidores LDAP em sua security.ldap.servers infraestrutura.

Essa configuração pode ser feita em um mongod ou mongos em execução usando setParameter.

Se não estiver configurado, mongod ou mongos não poderá usar autenticação ou autorização LDAP.

security.ldap.bind.queryUser

Tipo: string

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

A identidade com a qual o mongod ou mongos se liga, ao conectar ou executar consultas em um servidor LDAP.

Obrigatório apenas se alguma das seguintes afirmações for verdadeira:

• Utilizando autorização LDAP.

• Usando uma query LDAP para security.ldap.userToDNMapping.

• O servidor LDAP não permite ligações anônimas

Você deve usar queryUser com queryPassword.

Se não for definido, mongod ou mongos não tentará se vincular ao servidor LDAP.

Essa configuração pode ser feita em um mongod ou mongos em execução usando setParameter.

Observação

Os sistemas do Windows MongoDB podem utilizar o useOSDefaults ao invés do queryUser e queryPassword. Não é possível especificar queryUser e useOSDefaults ao mesmo tempo.

security.ldap.bind.queryPassword

Tipo: string ou array

Disponível apenas no MongoDB Enterprise.

A senha usada para vincular a um servidor LDAP ao utilizar o queryUser. Você deve usar queryPassword com queryUser.

Se não for definido, mongod ou mongos não tentará se vincular ao servidor LDAP.

Você pode definir essa configuração em um mongod ou mongos em execução usando setParameter.

O comando ldapQueryPassword setParameter aceita uma string ou uma array de strings. Se ldapQueryPassword for definido como uma array, o MongoDB tentará cada senha na ordem até que uma delas seja bem-sucedida. Use um array de senha para rolar sobre a senha da conta LDAP sem tempo de inatividade.

Observação

Os sistemas do Windows MongoDB podem utilizar o useOSDefaults ao invés do queryUser e queryPassword. Não é possível especificar queryPassword e useOSDefaults ao mesmo tempo.

security.ldap.bind.useOSDefaults

Tipo: booleano

Padrão: false

Novidades na versão 3.4: disponível no MongoDB Enterprise apenas para a plataforma Windows.

Permite que mongod ou mongos se autentiquem, ou se vinculem, usando suas credenciais de login do Windows ao se conectar ao servidor LDAP.

Necessário apenas se:

• Utilizando autorização LDAP.

• Usando uma query LDAP para username transformation.

• O servidor LDAP não permite ligações anônimas

Use useOSDefaults para substituir queryUser e queryPassword.

security.ldap.bind.method

Tipo: string

Padrão: simples

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

O método mongod ou mongos utiliza para autenticar em um servidor LDAP. Utilize com queryUser e queryPassword para conectar ao servidor LDAP.

method suporta os seguintes valores:

• simple - mongod ou mongos utiliza autenticação simples.

• sasl - mongod ou mongos usa o protocolo SASL para autenticação

Se você especificar sasl, você poderá configurar os mecanismos SASL disponíveis utilizando security.ldap.bind.saslMechanisms. mongod ou mongos padrão para usar DIGEST-MD5 mecanismo.

security.ldap.bind.saslMechanisms

Tipo: string

Padrão: DIGEST-MD5

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

Uma lista separada por vírgula de mecanismos SASL mongod ou mongos pode utilizar ao autenticar no servidor LDAP. O mongod ou mongos e o servidor LDAP devem concordar com pelo menos um mecanismo. O mongod ou mongos carrega dinamicamente quaisquer bibliotecas de mecanismos SASL instaladas na máquina host no tempo de execução.

Instale e configure as bibliotecas apropriadas para o(s) mecanismo(s) SASL selecionado(s) no host mongod ou mongos e no host do servidor LDAP remoto. Seu sistema operacional pode incluir determinadas bibliotecas SASL por padrão. Consulte a documentação associada a cada mecanismo SASL para obter orientação sobre instalação e configuração.

Se estiver usando o mecanismo GSSAPI SASL para uso com a autenticação Kerberos, verifique o seguinte para o computador host mongod ou mongos:

Linux

• A KRB5_CLIENT_KTNAME variável de ambiente é resolvida para o nome do cliente Linux Keytab Files para a máquina host. Para obter mais informações sobre variáveis de ambiente Kerberos, consulte a documentação do Kerberos.

• O keytab do cliente inclui um usuário principal para o mongod ou mongos usar ao conectar-se ao servidor LDAP e executar consultas LDAP.

Windows

Se estiver conectando a um servidor Active Directory, a configuração do Windows Kerberos gerará automaticamente um Ticket-Granting-Ticket quando o usuário faz login no sistema. Configure useOSDefaults como true para permitir que mongod ou use as credenciais geradas ao se conectar ao servidor do Active Directory e executar mongos consultas.

Configure method para sasl para utilizar esta opção.

Observação

Para obter uma lista completa dos mecanismos SASL, consulte a lista da IANA . Consulte a documentação do seu serviço LDAP ou Active Directory para identificar os mecanismos SASL compatíveis com o serviço.

MongoDB não é uma fonte de bibliotecas de mecanismo SASL nem a documentação do MongoDB é uma fonte definitiva para instalação ou configuração de qualquer mecanismo SASL. Para documentação e suporte, consulte o fornecedor ou proprietário da biblioteca do mecanismo SASL.

Para obter mais informações sobre SASL, consulte os seguintes recursos:

• Para Linux, consulte a documentação do Cyrus SASL.

• Para Windows, consulte a documentação do Windows SASL.

security.ldap.transportSecurity

Tipo: string

Padrão: tls

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

Por padrão, mongod ou mongos cria uma conexão segura TLS/SSL com o servidor LDAP.

Para sistemas do Linux, você deve configurar as Opções de TLS apropriadas no /etc/openldap/ldap.conf arquivo . O gerenciador de pacotes do seu sistema operacional cria esse arquivo como parte da instalação do MongoDB Enterprise, por meio da dependência . Consulte a libldap documentação do TLS Options na documentação do OpenLDAP ldap.conf para obter instruções mais completas.

Para o sistema do Windows, você deve adicionar os certificados CA do servidor LDAP à ferramenta de gerenciamento de certificados do Windows. O nome exato e a funcionalidade da ferramenta podem variar dependendo da versão do sistema operacional. Consulte a documentação da sua versão do Windows para obter mais informações sobre o gerenciamento de certificados.

Configure transportSecurity como none para desabilitar TLS/SSL entre mongod ou mongos e o servidor LDAP.

Aviso

Configurar transportSecurity para none transmite informações de texto simples e possivelmente credenciais entre mongod ou mongos e o servidor LDAP.

security.ldap.timeoutMS

Tipo: int

Padrão: 10000

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

A quantidade de tempo em milissegundos mongod ou mongos deve esperar que um servidor LDAP responda a uma solicitação.

Aumentar o valor de timeoutMS pode evitar a falha de conexão entre o servidor MongoDB e o servidor LDAP, se a origem da falha for um tempo limite de conexão. Diminuir o valor de timeoutMS reduz o tempo que o MongoDB espera por uma resposta do servidor LDAP.

Essa configuração pode ser feita em um mongod ou mongos em execução usando setParameter.

security.ldap.userToDNMapping

Tipo: string

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

Mapeia o nome de usuário fornecido para mongod ou mongos para autenticação em um Nome Distinto (DN) LDAP. Você pode precisar usar userToDNMapping para transformar um nome de usuário em um DN LDAP nos seguintes cenários:

• Executando autenticação LDAP com ligação LDAP simples, onde os usuários se autenticam no MongoDB com nomes de usuário que não são DNs LDAP completos.

• Utilizando um LDAP authorization query template que exige um DN.

• Transformar os nomes de usuário dos clientes que se autenticam no Mongo DB usando diferentes mecanismos de autenticação (por exemplo, x.509, kerberos) em um DN LDAP completo para autorização.

userToDNMapping espera uma string JSON-string com aspas que represente uma array ordenada de documentos. Cada documento contém uma expressão regular match e um modelo substitution ou ldapQuery usado para transformar o nome de usuário recebido.

Cada documento na array tem o seguinte formato:

{
  match: "<regex>"
  substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}

Campo	Descrição	Exemplo
match	Uma expressão regular (regex) formatada pelo ECMAScript para corresponder a um nome de usuário fornecido. Cada seção de parênteses representa um grupo de captura regex utilizado pelo substitution ou ldapQuery.	"(.+)ENGINEERING" "(.+)DBA"
substitution	Um modelo de formatação de nome distinto (DN) LDAP que converte o nome de autenticação correspondente pelo match regex em um DN LDAP. Cada valor numérico entre colchetes é substituído pelo grupo de captura de regex correspondente extraído do nome de usuário de autenticação através do match regex . O resultado da substituição deve ser um RFC4514 string que escapou.	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	Um modelo de formatação de consulta LDAP que insere o nome de autenticação correspondente ao match regex em um URI de consulta LDAP codificado respeitando RFC4515 e RFC4516. Cada valor numérico entre colchetes é substituído pelo grupo de captura de regex correspondente extraído do nome de usuário de autenticação por meio da match expressão . mongod O ou mongos executa a consulta no servidor LDAP para recuperar o DN LDAP para o usuário autenticado. mongod mongos ou exige exatamente um resultado retornado para que a transformação seja bem-sucedida, ou mongod ou mongos ignora essa transformação.	"ou=engineering,dc=example, dc=com??one?(user={0})"

Observação

Uma explicação da RFC4514, RFC4515, RFC4516, ou as queries LDAP estão fora do escopo da documentação do MongoDB. Revise o RFC diretamente ou use o recurso LDAP da sua preferência.

Para cada documento na array, você deve usar substitution ou ldapQuery. Você não pode especificar ambos no mesmo documento.

Ao realizar a autenticação ou autorização, mongod ou mongos percorre cada documento da array na ordem determinada, verificando o nome de usuário da autenticação em relação ao filtro match. Se uma correspondência for localizada, o mongod ou mongos aplicará a transformação e utilizará a saída para autenticar o usuário. mongod ou mongos não verifica os documentos restantes na array.

Se o documento fornecido não corresponder ao nome de autenticação fornecido, mongod ou mongos continuará percorrendo a lista de documentos para encontrar outras correspondências. Se nenhuma correspondência for encontrada em qualquer documento ou se a transformação descrita pelo documento falhar, mongod ou mongos retornará um erro.

mongod ou mongos também retornará um erro se uma das transformações não puder ser avaliada devido a falhas de rede ou autenticação no servidor LDAP. mongod ou mongos rejeita a solicitação de conexão e não verifica os documentos restantes na array.

A partir do MongoDB 5.0, userToDNMapping aceita uma string vazia "" ou array vazia [ ] no lugar de um documento de mapeamento. Se fornecer uma cadeia de caracteres vazia ou uma array vazia para userToDNMapping, o MongoDB mapeará o nome de usuário autenticado como o DN LDAP. Anteriormente, fornecer um documento de mapeamento vazio causaria falha no mapeamento.

Exemplo

O seguinte mostra dois documentos de transformação. O primeiro documento coincide com qualquer string que termine em @ENGINEERING, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex. O segundo documento coincide com qualquer string que termine em @DBA, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex.

Importante

Você deve passar a array para userToDNMapping como uma string.

"[
   {
      match: "(.+)@ENGINEERING.EXAMPLE.COM",
      substitution: "cn={0},ou=engineering,dc=example,dc=com"
   },
   {
      match: "(.+)@DBA.EXAMPLE.COM",
      ldapQuery: "ou=dba,dc=example,dc=com??one?(user={0})"
   }
]"

Um usuário com o nome de usuário alice@ENGINEERING.EXAMPLE.COM corresponde ao primeiro documento. O grupo de captura regex {0} corresponde à cadeia de caracteres alice. A saída resultante é o DN "cn=alice,ou=engineering,dc=example,dc=com".

Um usuário com o nome de usuário bob@DBA.EXAMPLE.COM corresponde ao segundo documento. O grupo de captura de regex {0} corresponde à string bob. A saída resultante é a consulta LDAP "ou=dba,dc=example,dc=com??one?(user=bob)". mongod ou mongos executa essa consulta no servidor LDAP, retornando o resultado "cn=bob,ou=dba,dc=example,dc=com".

Se userToDNMapping estiver desmarcado, mongod ou mongos não aplicará transformações ao nome de usuário ao tentar autenticar ou autorizar um usuário no servidor LDAP.

Essa configuração pode ser definida em um mongod ou mongos em execução usando o comando setParameter banco de dados.

security.ldap.authz.queryTemplate

Tipo: string

Novidades na versão 3.4: disponível apenas no MongoDB Enterprise.

Uma URL de query LDAP relativa formatada em conformidade com RFC4515 e RFC4516 que o executa para obter os grupos LDAP aos quais o usuário autenticado pertence. A query é relativa ao host ou hosts especificados mongod no security.ldap.servers.

Na URL, você pode usar os seguintes tokens de substituição:

Token de substituição	Descrição
{USER}	Substitui o nome de usuário autenticado, ou o nome de usuário do transformed se um userToDNMapping for especificado.
{PROVIDED_USER}	Substitui o nome de usuário fornecido, ou seja, antes da autenticação ou LDAP transformation. Novidades na versão 4.2.

Ao construir a URL de query, certifique-se de que a ordem dos parâmetros LDAP respeite RFC4516:

[ dn  [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

Se sua consulta incluir um atributo, mongod pressupõe que a consulta recupera uma lista dos DNs dos quais essa entidade é membro.

Se a sua consulta não incluir um atributo, mongod assume que a consulta recupera todas as entidades das quais o usuário é membro.

Para cada DN LDAP retornado pela consulta, o mongod atribui ao usuário autorizado um papel correspondente no banco de dados do admin. Se uma função no banco de dados admin corresponder exatamente ao DN, mongod concede ao usuário as funções e privilégios atribuídos a essa função. Consulte o método db.createRole() para mais informações sobre como criar papéis.

Exemplo

Esta query LDAP retorna quaisquer grupos listados no atributo memberOf do objeto de usuário LDAP.

"{USER}?memberOf?base"

Sua configuração LDAP pode não incluir o atributo memberOf como parte do esquema do usuário, pode possuir um atributo diferente para relatar a associação ao grupo ou pode não controlar a associação ao grupo por meio de atributos. Configure sua query com relação à sua configuração LDAP exclusiva.

Se não estiver configurado,mongod não poderá autorizar usuários usando LDAP.

Essa configuração pode ser feita em um mongod em execução usando o comando setParameter database.

Observação

Uma explicação da RFC4515, RFC4516 ou as queries LDAP estão fora do escopo da documentação do MongoDB. Revise o RFC diretamente ou use o recurso LDAP da sua preferência.

security.ldap.validateLDAPServerConfig

Tipo: booleano

Padrão: true

Disponível no MongoDB Enterprise

Um sinalizador que determina se a instância mongod ou mongos verifica a disponibilidade do LDAP server(s) como parte de sua inicialização:

• Se o true, a instância do mongod ou mongos executará a verificação de disponibilidade e somente continuará a iniciar se o servidor LDAP estiver disponível.

• Se false, a instância mongod ou mongos ignora a verificação de disponibilidade, ou seja, a instância é iniciada mesmo que o servidor LDAP não esteja disponível.

Parâmetros LDAP

setParameter.ldapUserCacheInvalidationInterval

Tipo: int

Padrão: 30

Para utilizar com servidores do mongod utilizando Autorização LDAP.

O intervalo (em segundos) mongod espera entre as descargas de cache do usuário externo. Depois que mongod libera o cache de usuário externo, o MongoDB readquire os dados de autorização do servidor LDAP na próxima vez que um usuário autorizado pelo LDAP realizar uma operação.

Aumentar o valor especificado aumenta a quantidade de tempo mongod e o servidor LDAP pode estar fora de sincronia, mas reduz a carga no servidor LDAP. Por outro lado, diminuir o valor especificado diminui o tempo mongod e o servidor LDAP pode estar fora de sincronia enquanto aumenta a carga no servidor LDAP.

setParameter:
   ldapUserCacheInvalidationInterval: <int>

storage.wiredTiger Opções

storage:
   wiredTiger:
      engineConfig:
         cacheSizeGB: <number>
         journalCompressor: <string>
         directoryForIndexes: <boolean>
         maxCacheOverflowFileSizeGB: <number>
      collectionConfig:
         blockCompressor: <string>
      indexConfig:
         prefixCompression: <boolean>

storage.wiredTiger.engineConfig.cacheSizeGB

Tipo: flutuação

Define o tamanho máximo do cache interno que o WiredTiger utiliza para todos os dados. A memória consumida por uma construção de índice (consulte maxIndexBuildMemoryUsageMegabytes) é separada da memória de cache do WiredTiger.

Os valores podem variar de 0.25 GB a 10000 GB.

A partir do MongoDB 3.4, o tamanho do cache interno padrão do WiredTiger é o maior entre:

• 50% de (RAM - 1 GB) ou

• 256 MB.

Por exemplo, em um sistema com um total de 4GB de RAM, o cache WiredTiger utiliza 1.5GB de RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). Por outro lado, em um sistema com um total de 1.25 GB de RAM WiredTiger aloca 256 MB para o cache do WiredTiger porque isso é mais da metade da RAM total menos um gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).

Observação

Em alguns casos, como quando executado em um container, o banco de dados pode ter restrições de memória inferiores à memória total do sistema. Nesses casos, esse limite de memória, em vez do total memória do sistema, é usado como a RAM máxima disponível.

Para ver o limite de memória, consulte hostInfo.system.memLimitMB.

Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão.

Com o WiredTiger, o MongoDB utiliza o cache interno do WiredTiger e o cache do sistema de arquivos.

Com o cache do sistema de arquivos, o MongoDB usa automaticamente toda a memória livre que não é usada pelo cache do WiredTiger ou por outros processos.

Observação

O storage.wiredTiger.engineConfig.cacheSizeGB limita o tamanho do cache interno do WiredTiger. O sistema operacional usa a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso, o sistema operacional usa qualquer RAM livre para armazenar em buffer os blocos do sistema de arquivos e o cache do sistema de arquivos.

Para acomodar os consumidores adicionais de RAM, pode ser necessário diminuir o tamanho do cache interno do WiredTiger.

O valor padrão do tamanho do cache interno do WiredTiger pressupõe que haja uma única instância mongod por máquina. Se uma única máquina contiver várias instâncias do MongoDB, você deverá diminuir a configuração para acomodar as outras instâncias mongod.

Se você executar mongod em um container (por exemplo, lxc, cgroups, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir storage.wiredTiger.engineConfig.cacheSizeGB para um valor menor que a quantidade de RAM disponível no contêiner. A quantidade exata depende dos outros processos em execução no container. Consulte memLimitMB.

storage.wiredTiger.engineConfig.journalCompressor

Padrão: snappy

Especifica o tipo de compactação a ser usada para compactar os dados do diário do WiredTiger.

Os compactadores disponíveis são:

• none

• snappy

• zlib

• zstd (Disponível a partir do MongoDB 4.2)

storage.wiredTiger.engineConfig.directoryForIndexes

Tipo: booleano

Padrão: false

Quando storage.wiredTiger.engineConfig.directoryForIndexes é true, mongod armazena índices e coleções em subdiretórios separados sob o diretório de dados (ou seja, storage.dbPath). Especificamente, o mongod armazena os índices em um subdiretório denominado index e os dados de coleta em um subdiretório denominado collection.

Ao utilizar um link simbólico, você pode especificar um local diferente para os índices. Especificamente, quando a instância do mongod não estiver em execução, mova o subdiretório do index para o destino e crie um link simbólico denominado index no diretório de dados para o novo destino.

storage.wiredTiger.engineConfig.zstdCompressionLevel

Tipo: inteiro

Padrão: 6

Especifica o nível de compressão aplicado ao utilizar o compressor zstd.

Os valores podem variar de 1 a 22.

Quanto maior o valor especificado para zstdCompressionLevel, maior a compressão que é aplicada.

Aplicável somente quando blockCompressor está definido como zstd.

Disponível a partir do MongoDB 5.0

storage.wiredTiger.collectionConfig.blockCompressor

Padrão: snappy

Especifica a compactação padrão para dados de collection. Você pode substituir isso por collection ao criar collections.

Os compactadores disponíveis são:

• none

• snappy

• zlib

• zstd (Disponível a partir do MongoDB 4.2)

storage.wiredTiger.collectionConfig.blockCompressor afeta todas as coleções criadas. Se você alterar o valor do storage.wiredTiger.collectionConfig.blockCompressor em uma implantação MongoDB existente, todas as novas coleções utilizarão o compressor especificado. Coleções existentes continuam a usar o compressor especificado quando foram criadas ou o compressor padrão naquele momento.

storage.wiredTiger.indexConfig.prefixCompression

Padrão: true

Habilita ou desabilita a compressão de prefixo para dados de índice.

Especifique true para storage.wiredTiger.indexConfig.prefixCompression para habilitar a compactação de prefixo para dados do índice ou false para desativar a compactação de prefixo para dados do índice.

A configuração storage.wiredTiger.indexConfig.prefixCompression afeta todos os índices criados. Se você alterar o valor de storage.wiredTiger.indexConfig.prefixCompression em uma implantação MongoDB existente, todos os novos índices utilizarão compressão de prefixo. Os índices existentes não são afetados.

storage.inmemory Opções

storage:
   inMemory:
      engineConfig:
         inMemorySizeGB: <number>

storage.inMemory.engineConfig.inMemorySizeGB

Tipo: flutuação

Padrão: 50% de RAM física menos 1 GB

Os valores podem variar de 256 MB a 10 TB e podem ser instáveis.

Quantidade máxima de memória para alocar dados do mecanismo de armazenamento in-memory, incluindo índices, oplog se o mongod fizer parte do conjunto de réplicas, conjunto de réplicas ou metadados de cluster fragmentados, etc.

Por padrão, o mecanismo de armazenamento na memória usa 50% da RAM física menos 1 GB.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.