Implantar conjunto de réplicas autogerenciado com autenticação de arquivo-chave
Nesta página
Visão geral
Para forçar o controle de acesso em um conjunto de réplicas, é necessário configurar:
Segurança entre membros do conjunto de réplicas usando Autenticação interna, e
Segurança entre clientes conectados e o conjunto de réplicas usando o controle de acesso baseado em função em implantações autogerenciadas.
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 conectar ao conjunto de réplicas, clientes como mongosh
precisam utilizar uma conta de usuário. Consulte Usuários e mecanismos de autenticação.
Cloud Manager e Ops Manager
Se você está usando ou está planejando usar o Cloud Manager ou o Ops Manager, consulte o manual do Cloud Manager ou o manual do Ops Manager para aplicar o controle de acesso.
Consideraçõ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 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.
Vinculação IP
mongod
e mongos
se vinculam ao localhost por padrão. Se os membros do sistema forem executados em hosts diferentes, ou se você desejar que os clientes remotos se conectem ao sistema, especifique --bind_ip
ou net.bindIp
.
Sistema operacional
Este tutorial se refere principalmente ao processo do mongod
. Os usuários do Windows devem utilizar o programa mongod.exe
no lugar.
Segurança de arquivos-chave
Recomendamos arquivos-chave apenas para ambientes de teste e desenvolvimento, devido às suas limitações de capacidade de gerenciamento e força criptográfica. Para ambientes de produção, é altamente recomendável usar x.509 certificados. Embora os keyfiles possam ser seguros em cenários específicos e controlados, eles apresentam desafios de escalabilidade e gerenciamento em sistemas complexos. x.509 Os certificados oferecem recursos de segurança mais robustos, permitem um melhor gerenciamento de chaves, suportam autenticação individual e aderem aos padrões do setor para proteção de dados confidenciais.
Mecanismos de usuários e autenticação
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.
Implemente um Novo Conjunto de Réplicas com Controle de Acesso a Arquivos-chave
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.
Crie um arquivo-chave.
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 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 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.
Copie o arquivo-chave para cada membro do conjunto de réplicas.
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 , como uma unidade USB ou um dispositivo de armazenamento conectado à mongod
rede.
Inicie cada nó do conjunto de réplicas com o controle de acesso habilitado.
Para cada membro no conjunto de réplicas, inicie o mongod
com o arquivo de configuração security.keyFile
ou a opção de linha de comando --keyFile
. A execução do mongod
com a opção de linha de comando --keyFile
ou a definição do arquivo de configuração security.keyFile
impõe a autenticação interna/de associação autogerenciada e o controle de acesso baseado em função em implantações autogerenciadas.
Arquivo de configuração
Se estiver usando um arquivo de configuração, defina
security.keyFile
para o caminho do arquivo-chave ereplication.replSetName
ao 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 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.
Linha de comando
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 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.
Para obter mais informações sobre as opções de linha de comando, consulte a página de referência mongod
.
Conecte-se a um nó do conjunto de réplicas pela interface localhost.
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
.
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.
Inicie o conjunto de réplicas.
A partir do mongosh
, execute o método rs.initiate()
.
rs.initiate()
pode pegar um documento opcional de configuração do conjunto de réplicas. No documento de configuração do conjunto de réplicas, inclua:
O campo
_id
definido com o nome do conjunto de réplicas especificado na opçãoreplication.replSetName
ou--replSet
.A array
members
com um documento por cada membro do conjunto de réplicas.
O exemplo a seguir inicia um conjunto de réplicas de três nós.
Importante
Execute rs.initiate()
em apenas uma instância mongod
para o conjunto de réplicas.
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.
rs.initiate( { _id : "myReplSet", members: [ { _id : 0, host : "mongo1.example.net:27017" }, { _id : 1, host : "mongo2.example.net:27017" }, { _id : 2, host : "mongo3.example.net:27017" } ] } )
rs.initiate()
desencadeia uma eleição e elege um dos nós para ser o primary.
Conecte-se ao primary antes de continuar. Use rs.status()
para localizar o nó primary.
Crie o administrador do usuário.
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, 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 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" } ] } )
Digite a senha quando solicitado. Consulte Funções do usuário de banco de dados para obter uma lista completa das funções integradas relacionadas às operações de administração do banco de dados.
Autenticar como administrador do usuário.
Autenticar no banco de dados do admin
.
No mongosh
, use db.auth()
para se autenticar. Por exemplo, abaixo há uma autenticação como administrador do usuário fred
:
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
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.
Crie o administrador do cluster.
A função clusterAdmin
concede acesso às operações de replicação, como configurar o conjunto de réplicas.
Crie um usuário de administrador do cluster e atribua o role do clusterAdmin
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
.
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
Digite a senha quando solicitado.
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.
Criar usuários adicionais (opcional).
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 obter mais informações sobre usuários, consulte Usuários em implantações autogerenciadas.
x.509 Autenticação interna
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 .