Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / / /

Atualize o cluster fragmentado autogerenciado para autenticação de arquivo-chave

Nesta página

  • Visão geral
  • Considerações
  • Antes de começar
  • Procedimentos
  • x.509 Autenticação interna

Para aplicar o controle de acesso em umcluster fragmentado do requer configuração:

Para este tutorial, cada membro do cluster fragmentado deve usar o mesmo mecanismo de autenticação interna e configurações. Isto significa aplicar autenticação interna em cada mongos e mongod no cluster.

O tutorial a seguir usa um arquivo-chave para habilitar a autenticação interna.

Forçar a autenticação interna também força o controle de acesso do usuário. Para se conectar ao conjunto de réplicas, clientes como mongosh precisam usar uma conta de usuário. Consulte Controle de acesso.

Se o Cloud Manager ou o Ops Manager estiver gerenciando sua implantação, a autenticação interna será imposta automaticamente.

Para configurar o Controle de Acesso em uma implantação gerenciada, consulte: Configure Access Control for MongoDB Deployments no manual do Cloud Manager ou no manual do MongoDB Ops Manager .

Importante

Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.

Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.

Binários do MongoDB, mongod e mongos, ligam-se ao localhost por padrão.

Este tutorial se refere principalmente ao processo do mongod. Os usuários do Windows devem utilizar o programa mongod.exe no lugar.

Os arquivos-chave são formas mínimas de segurança e são mais adequados para ambientes de teste ou desenvolvimento. Para ambientes de produção, recomendamos usar certificados x.509.

Este tutorial aborda a criação do número mínimo de usuários administrativos somente no banco de dados admin. Para a autenticação do usuário, o tutorial usa o mecanismo de autenticação SCRAM padrão. Os mecanismos de segurança de resposta a desafios são mais adequados para ambientes de teste ou desenvolvimento. Para ambientes de produção, recomendamos o uso de certificados x.509 ou Autenticação de Proxy LDAP autogerenciada (disponível apenas para MongoDB Enterprise) ou Autenticação Kerberos em Implantações Autogerenciadas (disponível apenas para MongoDB Enterprise).

Para obter detalhes sobre a criação de usuários para mecanismos de autenticação específicos, consulte as páginas específicas do mecanismo de autenticação.

Consulte ➤ Configurar o controle de acesso baseado em roles para obter as melhores práticas para criação e gerenciamento de usuários.

Em geral, para criar usuários para um cluster fragmentado, é preciso conectar ao mongos e adicionar os usuários do cluster fragmentado.

No entanto, algumas operações de manutenção exigem conexões diretas com fragmentos específicos em um cluster fragmentado. Para executar essas operações, você deve se conectar diretamente ao fragmento e autenticar como um usuário administrativo local do fragmento.

Os usuários locais do shard existem apenas no shard específico e só devem ser usados para manutenção e configuração específicas do shard. Você não pode se conectar ao mongos com usuários locais do shard.

Consulte a documentação de segurança Usuários em implementações autogerenciadas para obter mais informações.

A atualização de um cluster fragmentado para forçar o controle de acesso exige tempo de inatividade.

A partir do MongoDB 8.0, você pode usar a função directShardOperations para realizar operações de manutenção que exigem que você execute comandos diretamente em um shard.

Aviso

Executar comandos utilizando a função directShardOperations pode fazer com que seu cluster pare de funcionar corretamente e pode causar corrupção de dados. Use a função directShardOperations apenas para fins de manutenção ou sob a orientação do suporte do MongoDB . Quando terminar de executar as operações de manutenção, pare de usar a função directShardOperations .

1

Com a autenticação de keyfile, cada instância mongod ou mongos no cluster fragmentado usa o conteúdo do keyfile como a senha compartilhada para autenticar outros nós do sistema. Somente as instâncias mongod ou mongos com o keyfile correto podem entrar no cluster fragmentado.

Observação

Os arquivos de chaves para autenticação de associação interna usam o formato YAML para permitir várias chaves em um só arquivo. O formato YAML aceita:

  • Uma única string de chave (igual às versões anteriores)

  • Uma sequência de strings de chave

O formato YAML é compatível com os arquivos-chave de chave única existentes que usam o formato de arquivo de texto.

O comprimento de uma chave deve estar entre 6 e 1.024 caracteres e só pode conter caracteres no conjunto base64. Todos os membros do cluster fragmentado devem compartilhar pelo menos uma chave comum.

Observação

Em sistemas UNIX, o arquivo-chave não deve ter permissões de grupo ou mundiais. Em sistemas Windows, as permissões do arquivo-chave não são verificadas.

Você pode gerar um arquivo-chave usando qualquer método de sua escolha. Por exemplo, a operação a seguir usa openssl para gerar uma cadeia complexa pseudo-aleatória de 1024 caracteres para ser usada como senha compartilhada. Em seguida, ele usa chmod para alterar as permissões do arquivo e fornecer permissões de leitura somente para o proprietário do arquivo:

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

Consulte Keyfiles para obter detalhes adicionais e requisitos para usar keyfiles.

2

Cada servidor que hospeda um componente mongod ou mongos do cluster fragmentado deve conter uma cópia do arquivo-chave.

Copie o arquivo de chave para cada servidor hospedando os membros do cluster fragmentado. Certifique-se de que o usuário que executa as instâncias mongod ou mongos seja o proprietário do arquivo e possa acessá-lo-chave.

Evite armazenar o arquivo-chave em mídias de armazenamento que possam ser facilmente desconectadas do hardware que hospeda as instâncias mongod ou mongos, como um pen drive ou um dispositivo de armazenamento conectado à rede.

3

Conecte mongosh a um mongos.

sh.stopBalancer()

O balanceador pode não parar imediatamente se uma migração estiver em andamento. O método sh.stopBalancer() bloqueia o shell até que o balanceador pare.

A partir do MongoDB 6.0.3, a divisão automática de partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação.

Nas versões do MongoDB anteriores à 6.0.3, sh.stopBalancer() também desativa a divisão automática do cluster fragmentado.

Use sh.getBalancerState() para verificar se o balanceador parou.

sh.getBalancerState()

Importante

Não prossiga até que o balancer tenha parado de funcionar.

Consulte managed balanceador de cluster fragmentado para obter tutoriais sobre como configurar o comportamento do balanceador de cluster fragmentado.

4

Conecte mongosh a cada mongos e desligue-os.

Utilize o método db.shutdownServer() no reconhecimento de data center admin para desligar com segurança o mongos:

db.getSiblingDB("admin").shutdownServer()

Repita até que todas as instâncias do mongos no cluster estejam offline.

Após esta etapa ser concluída, todas as instâncias do mongos no cluster deverão estar offline.

5

Conecte mongosh a cada mongod no sistema do servidor de configuração e desligue-os.

Para sistemas de servidor de configuração de conjunto de réplicas, desligue o membro primário por último.

Utilize o método db.shutdownServer() no reconhecimento de data center admin para desligar com segurança o mongod:

db.getSiblingDB("admin").shutdownServer()

Repita até que todos os servidores de configuração estejam offline.

6

Para cada conjunto de réplicas de shard, conecte mongosh a cada membro mongod no conjunto de réplicas e desligue-os. Desligue o nó primary por último.

Utilize o método db.shutdownServer() no reconhecimento de data center admin para desligar com segurança o mongod:

db.getSiblingDB("admin").shutdownServer()

Repita esta etapa para cada conjunto de réplicas de fragmento até que todas as instâncias do mongod em todos os conjuntos de réplicas de fragmento estejam offline.

Quando essa etapa for concluída, todo o cluster fragmentado deverá estar offline.

7

Inicie cada mongod no conjunto de réplicas do servidor de configuração de configuração. Inclua a configuração keyFile . A configuração keyFile impõe a Autenticação Interna/Associação Autogerenciada e o Controle de Acesso Baseado em Função em Sistemas Autogerenciados.

Você pode especificar as configurações mongod por meio de um arquivo de configuração ou da linha de comando.

Arquivo de configuração

Se estiver usando um arquivo de configuração, para um conjunto de réplicas de servidor de configuração, defina security.keyFile para o caminho do arquivo-chave, sharding.clusterRole para configsvr e replication.replSetName para o nome do conjunto de réplicas do servidor de configuração.

security:
keyFile: <path-to-keyfile>
sharding:
clusterRole: configsvr
replication:
replSetName: <setname>
storage:
dbpath: <path>

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique a configuração net.bindIp.

Inicie o mongod especificando a opção --config e o caminho para o arquivo de configuração.

mongod --config <path-to-config>

Linha de comando

Se utilizar os parâmetros da linha de comando, para um conjunto de réplica do servidor de configuração, inicie o mongod com os parâmetros -keyFile, --configsvr e --replSet .

mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Para mais informações sobre as opções da linha de comando, consulte a página de referência do mongod .

Certifique-se de usar o nome original do conjunto de réplicas ao reiniciar cada membro. Você não pode alterar o nome de um conjunto de réplicas.

8

A execução de um mongod com o parâmetro keyFile força a autenticação interna autogerenciada/associação e o controle de acesso baseado em roles em sistemas autogerenciados.

Inicie cada mongod no conjunto de réplicas usando um arquivo de configuração ou a linha de comando.

Arquivo de configuração

Se estiver utilizando um arquivo de configuração, defina a opção security.keyFile para o caminho do arquivo-chave e a opção replication.replSetName para o nome original do conjunto de réplicas.

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <setname>
storage:
dbPath: <path>

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique a configuração net.bindIp.

Inicie o mongod especificando a opção --config e o caminho para o arquivo de configuração.

mongod --config <path-to-config-file>

Linha de comando

Se utilizar os parâmetros da linha de comando, inicie o mongod e especifique os parâmetros --keyFile e --replSet .

mongod --keyfile <path-to-keyfile> --replSet <setname> --dbpath <path>

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Para obter mais informações sobre parâmetros de inicialização, consulte a página de referência do mongod.

Certifique-se de usar o nome original do conjunto de réplicas ao reiniciar cada membro. Você não pode alterar o nome de um conjunto de réplicas.

Repita esta etapa até que todos os shards no cluster estejam online.

9

Importante

A Exceção de Localhost em Sistemas Autogerenciados permite que os clientes conectados pela interface localhost criem usuários em um mongod aplicando o controle de acesso. Após criar o primeiro usuário, a Exceção de Localhost em sistemas autogerenciados é fechada.

O primeiro usuário deve ter privilégios para criar outros usuários, como um usuário com userAdminAnyDatabase. Isso garante que você possa criar usuários adicionais depois que a exceção de Localhost em implantações autogerenciadas fecha.

Se pelo menos um usuário não tiver privilégios para criar usuários, depois que a exceção localhost for fechada, talvez você não consiga criar ou modificar usuários com novos privilégios e, portanto, não consiga acessar determinadas funções ou operações.

Para cada conjunto de réplicas de shard no cluster, conecte o mongosh ao membro primário pela interface localhost. Você deve executar mongosh na mesma máquina que o mongod de destino para usar a interface localhost.

Crie um usuário com a função userAdminAnyDatabase no banco de banco de dados admin . Esse usuário pode criar usuários adicionais para o conjunto de réplicas de shard, conforme necessário. A criação desse usuário também fecha a exceção do localhost em implantações autogerenciadas.

O exemplo a seguir cria o usuário local do shard fred no reconhecimento de data center admin .

Importante

As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.

Dica

Você pode usar o método passwordPrompt() em conjunto com vários métodos e comandos de gerenciamento de autenticação de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método ou comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo.

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)
10

A execução de um mongod com o parâmetro keyFile força a autenticação interna autogerenciada/associação e o controle de acesso baseado em roles em sistemas autogerenciados.

Inicie cada mongos no conjunto de réplicas usando um arquivo de configuração ou a linha de comando.

Arquivo de configuração

Se estiver usando um arquivo de configuração, defina security.keyFile como o caminho do arquivo-chave e sharding.configDB como o nome do conjunto de réplicas e pelo menos um membro do conjunto de réplicas no formato <replSetName>/<host:port> .

security:
keyFile: <path-to-keyfile>
sharding:
configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique a configuração net.bindIp.

Inicie o mongos especificando a opção --config e o caminho para o arquivo de configuração.

mongos --config <path-to-config-file>

Linha de comando

Se utilizar parâmetros da linha de comando, inicie o mongos e especifique os parâmetros --keyFile e --configdb.

mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Nesse ponto, todo o cluster fragmentado está online novamente e pode se comunicar internamente usando o arquivo de chave especificado. No entanto, programas externos como o mongosh precisam usar um usuário provisionado corretamente para ler ou gravar no cluster.

11

Conecte mongosh a uma das instâncias mongos pela interface localhost. Você deve executar mongosh na mesma máquina física que a instância mongos.

A interface localhost só está disponível porque nenhum usuário foi criado para o sistema. A interface localhost fecha após a criação do primeiro usuário.

12

Importante

Depois de criar o primeiro usuário, a exceção de local não estará mais disponível.

O primeiro usuário deve ter privilégios para criar outros usuários, como um usuário com userAdminAnyDatabase. Isso garante que você possa criar usuários adicionais depois que a exceção de Localhost em implantações autogerenciadas fecha.

Se pelo menos um usuário não tiver privilégios para criar usuários, depois que a exceção localhost for fechada, você não poderá criar ou modificar usuários e, portanto, talvez não consiga executar as operações necessárias.

Adicione um usuário utilizando o método db.createUser(). O usuário deve ter pelo menos o role userAdminAnyDatabase no banco de dados do admin.

Importante

As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.

O exemplo seguinte cria o usuário fred no banco de dados do admin:

Dica

Você pode usar o método passwordPrompt() em conjunto com vários métodos e comandos de gerenciamento de autenticação de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método ou comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo.

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

Consulte Roles do utilizador de banco de dados para obter uma lista completa das roles integradas e relacionadas às operações de administração do banco de dados.

13

Utilize o db.auth() para autenticar como o administrador de usuário para criar usuários adicionais:

Dica

Você pode usar o método passwordPrompt() em conjunto com vários métodos e comandos de gerenciamento de autenticação de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método ou comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo.

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

Digite a senha quando solicitado.

Como alternativa, conecte uma nova sessão mongosh ao membro do conjunto de réplicas de destino usando os parâmetros -u <username>, -p <password> e --authenticationDatabase "admin" . Você deve usar a Exceção de Localhost em Sistemas Autogerenciados para se conectar ao mongos.

mongosh -u "fred" -p --authenticationDatabase "admin"

Se você não especificar a senha para a opção de linha de comando -p, o mongosh solicitará a senha.

14

O usuário administrador do cluster tem o role clusterAdmin para o cluster fragmentado e não o administrador do cluster local do shard.

O exemplo seguinte cria o usuário ravi no banco de dados do admin.

Importante

As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.

Dica

Você pode usar o método passwordPrompt() em conjunto com vários métodos e comandos de gerenciamento de autenticação de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método ou comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo.

db.getSiblingDB("admin").createUser(
{
"user" : "ravi",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)

Veja as Roles de Administração de Cluster para obter uma lista completa de roles integrados relacionados às operações de conjunto de réplicas e operações de cluster fragmentado.

15

Para executar operações de fragmentação, autentique-se como usuário clusterAdmin com o método db.auth() ou como uma nova sessão mongosh com os parâmetros username, password e authenticationDatabase .

Observação

Este é o administrador do cluster para o cluster fragmentado e não o administrador do cluster local do shard.

16

Inicie o balanceador.

sh.startBalancer()

A partir do MongoDB 6.0.3, a divisão automática de partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação.

Nas versões MongoDB anteriores a 6.0.3, o sh.startBalancer() também habilita a divisão automática para o cluster fragmentado.

Use o sh.getBalancerState() para verificar se o balanceador foi iniciado.

Consulte managed balanceador de cluster fragmentado para obter tutoriais sobre o balanceador de cluster fragmentado.

17

Crie usuários para permitir que os clientes conectem e acessem o cluster fragmentado. Consulte Roles do utilizador do banco de dados para roles internos disponíveis, como read e readWrite. Você também pode querer usuários administrativos adicionais. Para obter mais informações sobre os usuários, consulte Usuários em implantações autogerenciadas.

Para criar usuários adicionais, você deve autenticar como um usuário com papéis do userAdminAnyDatabase ou userAdmin.

Para obter detalhes sobre como usar x.509 para autenticação interna, consulte Usar o certificado x.509 para autenticação de associação com o MongoDB autogerenciado.

Para atualizar da autenticação interna do keyfile para x.509 autenticação interna, consulte Atualizar o MongoDB autogerenciado da autenticação de keyfile para x. Autenticação do 509 .

Voltar

Implantar cluster fragmentado