Atualize o cluster compartilhado autogerenciado para autenticação de arquivo chave (sem tempo de inatividade)
Nesta página
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.
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:
clusterAdmin
no reconhecimento de data centeradmin
userAdmin
roles 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
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 demongos
para 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.transitionToAuth
definido comotrue
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.
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
mongos
para desligar.Use o método
db.shutdownServer()
no reconhecimento de data centeradmin
para desligar omongos
com segurança.db.getSiblingDB("admin").shutdownServer() 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 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
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 demongod
para 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.transitionToAuth
definido comotrue
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>
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
mongod
e use o métododb.shutdownServer()
admin
contra o reconhecimento de data center para desligar omongod
com segurança.db.getSiblingDB("admin").shutdownServer() 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 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()
admin
no reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() 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 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:
clusterAdmin
no reconhecimento de data centeradmin
userAdmin
roles 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
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 demongod
para 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.transitionToAuth
definido comotrue
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>
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
mongod
e use o métododb.shutdownServer()
admin
contra o reconhecimento de data center para desligar omongod
com segurança.db.getSiblingDB("admin").shutdownServer() 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 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()
admin
no reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() 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 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
mongos
para desligar.Use o método
db.shutdownServer()
no reconhecimento de data centeradmin
para desligar omongos
com segurança.db.getSiblingDB("admin").shutdownServer() 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 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
mongod
e use o métododb.shutdownServer()
admin
contra o reconhecimento de data center para desligar omongod
com segurança.db.getSiblingDB("admin").shutdownServer() 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 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()
admin
no reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() 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 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
mongod
e use o métododb.shutdownServer()
admin
contra o reconhecimento de data center para desligar omongod
com segurança.db.getSiblingDB("admin").shutdownServer() 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 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()
admin
no reconhecimento de data center .db.getSiblingDB("admin").shutdownServer() 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 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.
Autenticação interna do certificado x.509
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.509 Certificado para Autenticação de Associação com MongoDB.
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.