Atualize o cluster compartilhado autogerenciado para autenticação de arquivo chave (sem tempo de inatividade)
Visão geral
Importante
O procedimento a seguir se aplica a clusters fragmentados usando MongoDB 3.4 ou posterior.
Versões anteriores do MongoDB não suportam atualização sem tempo de inatividade. Para clusters fragmentados que usam versões anteriores do MongoDB, consulte Atualizar cluster fragmentado autogerenciado para autenticação de arquivo-chave.
Um cluster fragmentado do MongoDB pode impor a autenticação do usuário , bem como a autenticação interna de seus componentes para se proteger contra o acesso não autorizado.
O tutorial a seguir descreve um procedimento usando security.transitionToAuth para fazer a transição de um cluster fragmentado existente para impor a autenticação sem incorrer em tempo de inatividade.
Antes de tentar este tutorial, familiarize-se com o conteúdo deste documento.
Considerações
Cloud Manager e Ops Manager
Se você estiver usando o Cloud Manager ou o MongoDB Ops Manager para gerenciar seu sistema, consulte Configurar controle de acesso para sistemas do MongoDB nomanualCloud Manager ou no manual do MongoDB Ops Manager para impor a autenticação.
Vinculação IP
Binários do MongoDB, mongod e mongos, ligam-se ao localhost por padrão.
Mecanismos de autenticação interna e de cliente
Este tutorial configura a autenticação usando o SCRAM para autenticação do cliente e um arquivo-chave para autenticação interna.
Consulte a documentação Autenticação em implementações autogerenciadas para obter uma lista completa dos mecanismos de autenticação interna e de cliente disponíveis.
Arquitetura
Este tutorial pressupõe que cada conjunto de réplicas de shards, bem como o conjunto de réplicas do servidor de configuração, podem eleger um novo primário após reduzir seu primário existente.
Um conjunto de réplicas pode eleger um primário somente se as duas condições a seguir forem verdadeiras:
A maioria dos membros do conjunto de réplicas de votação está disponível após descer o primário.
Há pelo menos um membro secundário disponível que não está atrasado, oculto ou com prioridade 0.
Número mínimo de mongos instâncias
Certifique-se de que seu cluster fragmentado tenha pelo menos duas instâncias mongos disponíveis. Este tutorial requer a reinicialização de cada mongos no cluster. Se o cluster fragmentado tiver apenas uma instância do mongos , isso resultará em tempo de inatividade durante o período em que o mongos estiver offline.
Antes de começar
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 .
Impor o controle de acesso a arquivos-chave em um cluster fragmentado existente
Criar e distribuir o arquivo-chave
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 755 > <path-to-keyfile> chmod 400 <path-to-keyfile>
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.
Para obter mais informações sobre como usar arquivos-chave para autenticação interna, consulte Arquivos-chave.
Configurar usuários do administrador de cluster fragmentado e usuários do cliente
Você deve se conectar a um mongos para concluir as etapas nesta seção. Os usuários criados nessas etapas são usuários no nível do cluster e não podem ser usados para acessar conjuntos de réplicas de shards individuais.
Crie o usuário administrador.
Utilize o método db.createUser() para criar um usuário administrador e atribuir a ele as seguintes roles:
clusterAdminno reconhecimento de data centeradminuserAdminroles no reconhecimento de data centeradmin
Os clientes que executam operações de manutenção ou operações administrativas de usuários no cluster fragmentado devem se autenticar como esse usuário na conclusão deste tutorial. Crie esse usuário agora para garantir que você tenha acesso ao cluster após impor a autenticação.
admin = db.getSiblingDB("admin"); admin.createUser( { user: "admin", pwd: "<password>", roles: [ { role: "clusterAdmin", db: "admin" }, { role: "userAdmin", db: "admin" } ] } );
Importante
As senhas devem ser aleatórias, longas e complexas para evitar ou impedir o acesso malicioso.
Opcional: crie usuários adicionais para aplicativos clientes.
Além do usuário administrador, você pode criar usuários adicionais antes de impor a autenticação. Isso garante o acesso ao cluster fragmentado depois que você aplica totalmente a autenticação.
Exemplo
A operação a seguir cria o usuário joe no reconhecimento de data center marketing , atribuindo a esse usuário a função readWrite no reconhecimento de data center marketing .
db.getSiblingDB("marketing").createUser( { "user": "joe", "pwd": "<password>", "roles": [ { "role" : "readWrite", "db" : "marketing" } ] } )
Clientes autenticando como "joe" podem executar operações de leitura e gravação no reconhecimento de data center do marketing .
Consulte trigger de banco de dados Roles para roles fornecidas pelo MongoDB.
Consulte o tutorial Adicionar usuários para obter mais informações sobre como adicionar usuários. Considere as melhores práticas de segurança ao adicionar novos usuários.
Opcional: atualize os aplicativos do cliente para especificar as credenciais de autenticação.
Embora o cluster fragmentado não imponha autenticação no momento, você ainda pode atualizar os aplicativos do cliente para especificar as credenciais de autenticação ao se conectar ao cluster fragmentado. Isso pode evitar a perda de conectividade na conclusão deste tutorial.
Exemplo
A operação a seguir se conecta ao cluster fragmentado usando mongosh, autenticando como o usuário joe no banco de dados marketing.
mongosh --username "joe" --password "<password>" \ --authenticationDatabase "marketing" --host mongos1.example.net:27017
Se o seu aplicativo usa um driver do MongoDB, consulte a documentação do driver associado para obter instruções sobre como criar uma conexão autenticada.
Faça a transição de cada instância para aplicar a autenticação mongos
Crie um novo mongos arquivo de configuração.
Para cada mongos:
Copie o arquivo de configuração
mongosexistente, atribuindo a ele um nome distinto, como<filename>-secure.conf(ou.cfgse estiver usando Windows). Você usará esse novo arquivo de configuração para fazer a transição demongospara impor a autenticação no cluster fragmentado. Mantenha o arquivo de configuração original para fins de backup.No novo arquivo de configuração, adicione as seguintes configurações:
security.transitionToAuthdefinido comotruesecurity.keyFiledefinido como o caminho do arquivo-chave.Se estiver usando um mecanismo de autenticação interna diferente, especifique as configurações apropriadas para o mecanismo.
security: transitionToAuth: true keyFile: <path-to-keyfile> O novo arquivo de configuração deve conter todas as definições de configuração usadas anteriormente pelo
mongos, bem como as novas definições de segurança.
Um de cada vez, reinicie o mongos com o novo arquivo de configuração.
Observação
Siga o procedimento para reiniciar a instância mongos , um mongos de cada vez:
Conecte ao
mongospara desligar.Use o método
db.shutdownServer()no reconhecimento de data centeradminpara desligar omongoscom segurança.db.getSiblingDB("admin").shutdownServer() Reinicie o
mongoscom o novo arquivo de configuração, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongos-secure.conf:mongos --config <path>/mongos-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o novo arquivo de configuração.
Repita o processo de reinicialização para a próxima instância mongos até que todas as instâncias mongos no cluster fragmentado tenham sido reiniciadas.
No final desta seção, todas as instâncias do mongos no cluster fragmentado estão sendo executadas com autenticação interna do security.transitionToAuth e security.keyFile .
Membros do conjunto de réplicas do servidor de configuração de transição para impor a autenticação
Crie um novo mongod arquivo de configuração.
Para cada mongod no conjunto de réplicas do servidor de configuração,
Copie o arquivo de configuração
mongodexistente, atribuindo a ele um nome distinto, como<filename>-secure.conf(ou.cfgse estiver usando Windows). Você usará esse novo arquivo de configuração para fazer a transição demongodpara impor a autenticação no cluster fragmentado. Mantenha o arquivo de configuração original para fins de backup.No novo arquivo de configuração, adicione as seguintes configurações:
security.transitionToAuthdefinido comotruesecurity.keyFiledefinido como o caminho do arquivo-chave.Se estiver usando um mecanismo de autenticação interna diferente, especifique as configurações apropriadas para o mecanismo.
security: transitionToAuth: true keyFile: <path-to-keyfile>
Um de cada vez, reinicie o mongod com o novo arquivo de configuração.
Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .
Para reiniciar os membros secundários um de cada vez,
Conecte-se ao
mongode use o métododb.shutdownServer()admincontra o reconhecimento de data center para desligar omongodcom segurança.db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o novo arquivo de configuração, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o novo arquivo de configuração.
Quando este membro estiver ativo, repita para o próximo membro secundário .
Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:
Conecte-se ao
mongod.Use o método
rs.stepDown()para descer a primária e trigger uma eleição.rs.stepDown() Você pode usar o método
rs.status()para garantir que o conjunto de réplicas tenha escolhido um novo primário.Depois de descer o primário e um novo primário tiver sido eleito, encerre o primário antigo usando o método {
db.shutdownServer()adminno reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o novo arquivo de configuração, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o novo arquivo de configuração.
No final desta seção, todas as instâncias do mongod no conjunto de réplicas do servidor de configuração estão sendo executadas com autenticação interna do security.transitionToAuth e security.keyFile .
Faça a transição de cada membro do conjunto de réplicas de shard para impor a autenticação
Crie o administrador local do shard
Em um cluster fragmentado que impõe autenticação, cada conjunto de réplicas de shard deve ter seu próprio administrador local de shard. Você não pode usar um administrador local do fragmento para que um fragmento acesse outro fragmento ou o cluster fragmentado.
Conecte ao membro primary de cada conjunto de réplicas de shard e crie um usuário com o método db.createUser() , atribuindo a ele as seguintes roles:
clusterAdminno reconhecimento de data centeradminuserAdminroles no reconhecimento de data centeradmin
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: "admin", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "clusterAdmin", db: "admin" }, { role: "userAdmin", db: "admin" } ] } )
Na conclusão deste tutorial, se você quiser se conectar ao fragmento para realizar operações de manutenção que exijam conexão direta com um fragmento, deverá autenticar como administrador local do fragmento.
Observação
As conexões diretas com um fragmento devem ser apenas para manutenção e configuração específicas do fragmento. Em geral, os clientes devem se conectar ao cluster fragmentado por meio do mongos.
Procedimento
Faça a transição de um conjunto de réplicas de fragmento de cada vez, repita essas etapas para cada conjunto de réplicas de fragmento no cluster fragmentado.
Crie um novo mongod arquivo de configuração.
Para cada mongod no conjunto de réplicas de fragmentos,
Copie o arquivo de configuração
mongodexistente, atribuindo a ele um nome distinto, como<filename>-secure.conf(ou.cfgse estiver usando Windows). Você usará esse novo arquivo de configuração para fazer a transição demongodpara impor a autenticação no cluster fragmentado. Mantenha o arquivo de configuração original para fins de backup.No novo arquivo de configuração, adicione as seguintes configurações:
security.transitionToAuthdefinido comotruesecurity.keyFiledefinido como o caminho do arquivo-chave.Se estiver usando um mecanismo de autenticação interna diferente, especifique as configurações apropriadas para o mecanismo.
security: transitionToAuth: true keyFile: <path-to-keyfile>
Um de cada vez, reinicie o mongod com o novo arquivo de configuração.
Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .
Para reiniciar os membros secundários um de cada vez,
Conecte-se ao
mongode use o métododb.shutdownServer()admincontra o reconhecimento de data center para desligar omongodcom segurança.db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o novo arquivo de configuração, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o novo arquivo de configuração.
Quando esse membro estiver ativo, repita para o próximo membro secundário do conjunto de réplicas até que todos os secundários tenham sido atualizados.
Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:
Conecte-se ao
mongod.Use o método
rs.stepDown()para descer a primária e trigger uma eleição.rs.stepDown() Você pode usar o método
rs.status()para garantir que o conjunto de réplicas tenha escolhido um novo primário.Depois de descer o primário e um novo primário tiver sido eleito, encerre o primário antigo usando o método {
db.shutdownServer()adminno reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o novo arquivo de configuração, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o novo arquivo de configuração.
Neste ponto do tutorial, todos os componentes do cluster fragmentado estão sendo executados com a autenticação interna --transitionToAuth e security.keyFile . O cluster fragmentado tem pelo menos um usuário administrativo, e cada conjunto de réplicas de fragmento tem um usuário administrativo local do fragmento.
As seções restantes envolvem tirar o cluster fragmentado do estado de transição para impor totalmente a autenticação.
Reinicie cada mongos instância sem transitionToAuth
Importante
No final desta seção, os clientes devem especificar as credenciais de autenticação para se conectar ao cluster fragmentado. Atualize os clientes para especificar as credenciais de autenticação antes de concluir esta seção para evitar a perda de conectividade.
Para concluir a transição para aplicar totalmente a autenticação no cluster fragmentado, você deve reiniciar cada instância do mongos sem a configuração do security.transitionToAuth .
Remova transitionToAuth dos mongos arquivos de configuração do.
Remova a chave security.transitionToAuth e seu valor dos arquivos de configuração mongos criados durante este tutorial. Deixe a configuração security.keyFile adicionada no tutorial.
security: keyFile: <path-to-keyfile>
Reinicie o mongos com o arquivo de configuração atualizado.
Observação
Siga o procedimento para reiniciar a instância mongos , um mongos de cada vez:
Conecte ao
mongospara desligar.Use o método
db.shutdownServer()no reconhecimento de data centeradminpara desligar omongoscom segurança.db.getSiblingDB("admin").shutdownServer() Reinicie o
mongoscom o arquivo de configuração atualizado, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o arquivo de configuração atualizado foi denominadomongos-secure.conf:mongos --config <path>/mongos-secure.conf
No final desta seção, todas as instâncias do mongos impõem a autenticação do cliente e a autenticação interna do security.keyFile .
Reinicie cada membro do conjunto de réplicas do servidor de configuração sem transitionToAuth
Importante
No final desta etapa, os clientes devem especificar credenciais de autenticação para se conectar ao conjunto de réplica do servidor de configuração. Atualize os clientes para especificar as credenciais de autenticação antes de concluir esta seção para evitar a perda de conectividade.
Para concluir a transição para aplicar totalmente a autenticação no cluster fragmentado, você deve reiniciar cada instância do mongod sem a configuração do security.transitionToAuth .
Remova transitionToAuth dos mongod arquivos de configuração do.
Remova a chave security.transitionToAuth e seu valor dos arquivos de configuração do servidor de configuração criados durante este tutorial. Deixe a configuração security.keyFile adicionada no tutorial.
security: keyFile: <path-to-keyfile>
Um de cada vez, reinicie o mongod com o arquivo de configuração atualizado.
Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .
Para reiniciar os membros secundários um de cada vez,
Conecte-se ao
mongode use o métododb.shutdownServer()admincontra o reconhecimento de data center para desligar omongodcom segurança.db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o arquivo de configuração atualizado, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o arquivo de configuração atualizado.
Quando este membro estiver ativo, repita para o próximo membro secundário .
Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:
Conecte-se ao
mongod.Use o método
rs.stepDown()para descer a primária e trigger uma eleição.rs.stepDown() Você pode usar o método
rs.status()para garantir que o conjunto de réplicas tenha escolhido um novo primário.Depois de descer o primário e um novo primário tiver sido eleito, encerre o primário antigo usando o método {
db.shutdownServer()adminno reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o arquivo de configuração atualizado, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o arquivo de configuração atualizado.
No final desta seção, todas as instâncias do mongod no conjunto de réplicas do servidor de configuração impõem a autenticação do cliente e a autenticação interna do security.keyFile .
Reinicie cada membro em cada conjunto de réplicas de fragmento sem transitionToAuth
Importante
Ao final desta etapa, os clientes devem especificar as credenciais de autenticação para se conectar ao conjunto de réplicas do shard. Atualize os clientes para especificar as credenciais de autenticação antes de concluir esta seção para evitar a perda de conectividade.
Para concluir a transição para aplicar totalmente a autenticação no cluster fragmentado, você deve reiniciar cada membro de cada conjunto de réplicas de shard no cluster fragmentado sem a configuração security.transitionToAuth .
Faça a transição de um conjunto de réplicas de fragmento de cada vez, repita essas etapas para cada conjunto de réplicas de fragmento no cluster fragmentado.
Remova transitionToAuth dos mongod arquivos de configuração do.
Remova a chave security.transitionToAuth e seu valor dos arquivos de configuração do servidor de configuração criados durante este tutorial. Deixe a configuração security.keyFile adicionada no tutorial.
security: keyFile: <path-to-keyfile>
Um de cada vez, reinicie o mongod com o arquivo de configuração atualizado.
Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .
Para reiniciar os membros secundários um de cada vez,
Conecte-se ao
mongode use o métododb.shutdownServer()admincontra o reconhecimento de data center para desligar omongodcom segurança.db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o arquivo de configuração atualizado, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o arquivo de configuração atualizado.
Quando este membro estiver ativo, repita para o próximo membro secundário .
Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:
Conecte-se ao
mongod.Use o método
rs.stepDown()para descer a primária e trigger uma eleição.rs.stepDown() Você pode usar o método
rs.status()para garantir que o conjunto de réplicas tenha escolhido um novo primário.Depois de descer o primário e um novo primário tiver sido eleito, encerre o primário antigo usando o método {
db.shutdownServer()adminno reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() Reinicie o
mongodcom o arquivo de configuração atualizado, especificando o caminho para o arquivo de configuração utilizando--config. Por exemplo, se o novo arquivo de configuração foi denominadomongod-secure.conf:mongod --config <path>/mongod-secure.conf onde
<path>representa o caminho do sistema para a pasta que contém o arquivo de configuração atualizado.
No final desta seção, todas as instâncias do mongos e mongod no cluster fragmentado forçam a autenticação do cliente e a autenticação interna do security.keyFile . Os clientes só podem se conectar ao cluster fragmentado usando o mecanismo de autenticação de cliente configurado. Componentes adicionais só podem entrar no cluster especificando o arquivo de chave correto.
X.509 Autenticação interna do certificado
O MongoDB suporta autenticação de certificado X.509 para uso com uma conexão TLS/SSL segura. Os membros do cluster fragmentado e os membros do conjunto de réplicas podem usar certificados X.509 para verificar sua associação ao cluster ou ao conjunto de réplicas em vez de usar Keyfiles.
Para obter detalhes sobre o uso de certificados X.509 para autenticação interna, consulte Usar certificados X.509 para autenticação de associação com MongoDB autogerenciado.
Atualização do MongoDB autogerenciado de autenticação de arquivo de chave para X.509 Autenticação descreve como atualizar o mecanismo de autenticação interno de um sistema de autenticação baseada em arquivo de chave para X.509 Autenticação baseada em certificado.