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

Atualizar conjunto de réplicas para autenticação de arquivo-chave

Nesta página

  • Visão geral
  • Considerações
  • Impor controle de acesso de arquivo chave no conjunto de réplicas existente
  • x.509 Autenticação interna

Para aplicar o controle de acesso em um conjunto de réplica existente é necessário configurar:

Para este tutorial, cada membro do conjunto de réplicas usa o mesmo mecanismo de autenticação interna e configurações.

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. Veja os usuários.

Se o Cloud Manager ou o Ops Manager estiverem gerenciando sua implantação, consulte o manual do Cloud Manager ou o manual do Ops Manager para aplicar o controle de acesso.

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 clusters em um horizonte de rede dividido. A partir do MongoDB 5.0, os nós que são configurados apenas com um endereço IP falham na validação de inicialização e não iniciam.

Os binários do MongoDB, mongod e mongos, vinculam-se a localhost por padrão.

Este tutorial usa os programas mongod . Em vez disso, os usuários do Windows devem usar o programa mongod.exe .

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 x.509 certificados.

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 usar x.509 certificados ou Autenticação de Proxy LDAP (disponível apenas para MongoDB Enterprise) ou Autenticação Kerberos (disponível apenas para o 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 controle de acesso baseado em funções para obter as práticas recomendadas para criação e gerenciamento de usuários.

O procedimento a seguir para forçar o controle de acesso exige tempo de inatividade. Para obter um procedimento que não exija tempo de inatividade, consulte Atualizar conjunto de réplicas para autenticação de arquivo-chave (sem tempo de inatividade) .

1

Com a autenticação do arquivo -chave, cada instância do mongod no conjunto de réplicas utiliza o conteúdo do arquivo-chave como a senha compartilhada para autenticar outros membros no sistema. Somente instâncias mongod com o arquivo-chave correto podem entrar no conjunto de réplicas.

Observação

Os arquivos de chave para autenticação de associação interna usam o formato YAML para permitir várias chaves em um arquivo de chave. 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 ter entre 6 e 1024 caracteres e só pode conter caracteres no conjunto base64. Todos os membros do conjunto de réplicas 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

Copie o arquivo-chave para cada servidor que hospeda os membros do conjunto de réplicas. Certifique-se de que o usuário que executa as instâncias mongod seja o proprietário do arquivo e possa acessar o arquivo-chave.

Evite armazenar o arquivo-chave em meios de armazenamento que podem ser facilmente desconectados do hardware hospedando as instâncias do mongod , como uma unidade USB ou um dispositivo de armazenamento conectado à rede.

3

Desligue cada mongod no conjunto de réplica, começando com os segundos. Continue até que todos os membros do conjunto de réplicas estejam off-line, inclusive arbiters. O principal deve ser o último membro desligado para evitar possíveis reversões.

Para encerrar um mongod, conecte cada mongod usando mongosh e emita o db.shutdownServer() no banco de dados admin :

use admin
db.shutdownServer()

Ao final dessa etapa, todos os membros do conjunto de réplicas devem estar offline.

4

Reinicie cada mongod no conjunto de réplicas com o arquivo de configuração security.keyFile ou com a opção de linha de comando --keyFile . A execução mongod com a opção de linha de comando --keyFile ou a configuração do arquivo de configuração security.keyFile impõe a Autenticação Interna/Associação e o Controle de Acesso Baseado em Função.

Se estiver usando um arquivo de configuração, defina

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

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>
net:
bindIp: localhost,<hostname(s)|ip address(es)>

Inicie o mongod utilizando o arquivo de configuração:

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

Para obter mais informações sobre o arquivo de configuração, consulte opções de configuração.

Se utilizar as opções da linha de comando, inicie o mongod com as seguintes opções:

  • --keyFile definido como o caminho do arquivo-chave e

  • --replSet definido para o nome do conjunto de réplicas.

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.

mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

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 clusters em um horizonte de rede dividido. A partir do MongoDB 5.0, os nós que são configurados apenas com um endereço IP falham na validação de inicialização e não iniciam.

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

5

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

Use rs.status() para identificar o membro primário do conjunto de réplicas. Se você estiver conectado à primária, continue para a próxima etapa. Caso contrário, conecte mongosh ao primário pela interface localhost.

Importante

Você deve se conectar ao primário antes de continuar.

6

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 o userAdminAnyDatabase. Isso garante que você possa criar usuários adicionais após o fechamento da Exceção Localhost .

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

Você deve estar conectado ao primary para criar usuários.

O exemplo a seguir cria o usuário fred com 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.

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: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

Digite a senha quando solicitado. Consulte Roles do usuário de banco de dados para obter uma lista completa das roles integradas e relacionadas às operações de administração do banco de dados.

7

Autenticar no banco de dados do admin.

Em mongosh, use db.auth() para autenticar. Por exemplo, o seguinte se autentica como administrador do usuário fred:

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 .

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

Como alternativa, conecte uma nova instância do mongosh ao membro do conjunto de réplicas do primário utilizando os parâmetros -u <username>, -p <password> e --authenticationDatabase.

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.

8

O usuário de administrador do cluster tem a role clusterAdmin , que concede acesso às operações de replicação.

Crie um usuário de administrador do cluster e atribua o role clusterAdmin no banco de dados 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 .

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

Digite a senha quando solicitado.

Consulte Cluster Administration Roles para obter uma lista completa de funções internas relacionadas a operações de conjunto de réplicas.

9

Crie usuários para permitir que os clientes se conectem e interajam com o conjunto de réplicas. Consulte Funções de utilizador de banco de dados para obter informações sobre as funções internas básicas a serem usadas na criação de usuários somente leitura e de leitura e gravação.

Você também pode querer usuários administrativos adicionais. Para mais informações sobre usuários, consulte Usuários.

Para obter detalhes sobre como usar x.509 para autenticação interna, consulte Usar x.509 Certificado para Autenticação de Associação.

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

← Distribuir conjunto de réplicas com autenticação de arquivo de chave