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

Atualizar cluster fragmentado autogerenciado para autenticação de arquivo chave (sem tempo de inatividade)

Nesta página

  • Visão geral
  • Considerações
  • Impor o controle de acesso a arquivos-chave em um cluster fragmentado existente
  • Autenticação interna do certificado x.509

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.

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.

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

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.

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.

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.

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.

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.

1

Utilize o método db.createUser() para criar um usuário administrador e atribuir a ele as seguintes roles:

  • clusterAdmin no reconhecimento de data center admin

  • userAdmin roles no reconhecimento de data center admin

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.

2

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.

3

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.

1

Para cada mongos:

  1. Copie o arquivo de configuração mongos existente, atribuindo a ele um nome distinto, como <filename>-secure.conf (ou .cfg se estiver usando Windows). Você usará esse novo arquivo de configuração para fazer a transição de mongos para impor a autenticação no cluster fragmentado. Mantenha o arquivo de configuração original para fins de backup.

  2. No novo arquivo de configuração, adicione as seguintes configurações:

    • security.transitionToAuth definido como true

    • security.keyFile definido 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.

2

Observação

Se o seu cluster tiver apenas um mongos, esta etapa resultará em tempo de inatividade enquanto o mongos estiver offline.

Siga o procedimento para reiniciar a instância mongos , um mongos de cada vez:

  1. Conecte ao mongos para desligar.

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

    db.getSiblingDB("admin").shutdownServer()
  3. Reinicie o mongos com 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 denominado mongos-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 .

1

Para cada mongod no conjunto de réplicas do servidor de configuração,

  1. Copie o arquivo de configuração mongod existente, atribuindo a ele um nome distinto, como <filename>-secure.conf (ou .cfg se estiver usando Windows). Você usará esse novo arquivo de configuração para fazer a transição de mongod para impor a autenticação no cluster fragmentado. Mantenha o arquivo de configuração original para fins de backup.

  2. No novo arquivo de configuração, adicione as seguintes configurações:

    • security.transitionToAuth definido como true

    • security.keyFile definido 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>
2

Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .

  1. Para reiniciar os membros secundários um de cada vez,

    1. Conecte-se ao mongod e use o método db.shutdownServer() admin contra o reconhecimento de data center para desligar o mongod com segurança.

      db.getSiblingDB("admin").shutdownServer()
    2. Reinicie o mongod com 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 denominado mongod-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 .

  2. Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:

    1. Conecte-se ao mongod.

    2. 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.

    3. 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() admin no reconhecimento de data center .

      db.getSiblingDB("admin").shutdownServer()
    4. Reinicie o mongod com 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 denominado mongod-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 .

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:

  • clusterAdmin no reconhecimento de data center admin

  • userAdmin roles no reconhecimento de data center admin

Dica

Você pode usar o método passwordPrompt() em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/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.

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.

1

Para cada mongod no conjunto de réplicas de fragmentos,

  1. Copie o arquivo de configuração mongod existente, atribuindo a ele um nome distinto, como <filename>-secure.conf (ou .cfg se estiver usando Windows). Você usará esse novo arquivo de configuração para fazer a transição de mongod para impor a autenticação no cluster fragmentado. Mantenha o arquivo de configuração original para fins de backup.

  2. No novo arquivo de configuração, adicione as seguintes configurações:

    • security.transitionToAuth definido como true

    • security.keyFile definido 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>
2

Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .

  1. Para reiniciar os membros secundários um de cada vez,

    1. Conecte-se ao mongod e use o método db.shutdownServer() admin contra o reconhecimento de data center para desligar o mongod com segurança.

      db.getSiblingDB("admin").shutdownServer()
    2. Reinicie o mongod com 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 denominado mongod-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.

  2. Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:

    1. Conecte-se ao mongod.

    2. 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.

    3. 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() admin no reconhecimento de data center .

      db.getSiblingDB("admin").shutdownServer()
    4. Reinicie o mongod com 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 denominado mongod-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.

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 .

1

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>
2

Observação

Se o seu cluster tiver apenas um mongos, esta etapa resultará em tempo de inatividade enquanto o mongos estiver offline.

Siga o procedimento para reiniciar a instância mongos , um mongos de cada vez:

  1. Conecte ao mongos para desligar.

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

    db.getSiblingDB("admin").shutdownServer()
  3. Reinicie o mongos com 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 denominado mongos-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 .

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 .

1

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>
2

Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .

  1. Para reiniciar os membros secundários um de cada vez,

    1. Conecte-se ao mongod e use o método db.shutdownServer() admin contra o reconhecimento de data center para desligar o mongod com segurança.

      db.getSiblingDB("admin").shutdownServer()
    2. Reinicie o mongod com 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 denominado mongod-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 .

  2. Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:

    1. Conecte-se ao mongod.

    2. 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.

    3. 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() admin no reconhecimento de data center .

      db.getSiblingDB("admin").shutdownServer()
    4. Reinicie o mongod com 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 denominado mongod-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 .

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.

1

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>
2

Reinicie o conjunto de réplicas, um membro por vez, começando pelos membros secundários .

  1. Para reiniciar os membros secundários um de cada vez,

    1. Conecte-se ao mongod e use o método db.shutdownServer() admin contra o reconhecimento de data center para desligar o mongod com segurança.

      db.getSiblingDB("admin").shutdownServer()
    2. Reinicie o mongod com 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 denominado mongod-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 .

  2. Depois que todos os membros secundários tiverem sido reiniciados e estiverem ativos, reinicie o primary:

    1. Conecte-se ao mongod.

    2. 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.

    3. 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() admin no reconhecimento de data center .

      db.getSiblingDB("admin").shutdownServer()
    4. Reinicie o mongod com 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 denominado mongod-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.

O MongoDB oferece suporte à 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 como usar x.509 certificados para autenticação interna, consulte Usar x. Certificado 509 para autenticação de associação com MongoDB autogerenciado.

Atualize o MongoDB autogerenciado da autenticação Keyfile para x.509 Autenticação descreve como atualizar o mecanismo de autenticação interno de um sistema de autenticação baseada em keyfile para x.509 autenticação baseada em certificado.

Voltar

Atualizar cluster fragmentado

Próximo

Girar chaves de conjunto de réplicas