Alterne x.509 certificados para usar valores de extensão em clusters autogerenciados

Nesta página

Sobre esta tarefa

Passos
Saiba mais

Novidades na versão 7.0.

Os membros do cluster podem usar certificados x.509 para autenticação de associação para identificar outros servidores na mesma implantação. Este tutorial descreve como executar uma atualização contínua para migrar do uso de atributos de nome distinto (DN) do certificado para o uso de valores de extensão para identificar membros de um cluster.

Quando um servidor configurado com a configuração recebe uma solicitação de net.tls.clusterAuthX509.extensionValue conexão, ele compara a string de valor de extensão dos certificados extensionValue tlsClusterAuthX509Override apresentados com os valores configurados da configuração e do parâmetro. Se os valores corresponderem, ele tratará a conexão como um membro do cluster.

Os clusters que adotam novos certificados podem usar o parâmetro para aceitar tlsClusterAuthX509Override x.509 certificados com diferentes atributos DN durante o procedimento de rotação de certificados. Quando todos os membros usarem certificados com o novo valor, remova a substituição para começar a rejeitar os certificados agora desatualizados.

Sobre esta tarefa

Considere um conjunto de réplicas em que os certificados de membro, definidos usando as configurações e, têm atributos de DN (Distinguished Name) que usam clusterFile certificateKeyFile a MongoDB organização e a MongoDB Server unidade organizacional. Estes atributos DN são definidos usando a net.tls.clusterAuthX509.attributes configuração.

security:
  clusterAuthMode:      x509
net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/10gen-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/10gen-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server

Observação

O procedimento a seguir pressupõe que os novos certificados x.509 atendam ao certificado de associação e a todos os outros requisitos e que a configuração do cluster identifica certificados de mesmo nível usando valores de nome distinto (DN). Para obter mais informações, consulte Requisitos de certificado de membro.

Passos

Estas etapas atualizam certificados de membro para utilizar novos509 certificados x. em um cluster configurado com a attributes configuração.

Inicialmente, os clusters identificam membros usando valores de nome diferenciado. Com os novos certificados, os servidores identificam membros usando o valor de extensão mongodb://example.mongodb.net e ignoram os atributos do certificado.

Atualizar a configuração de associação do cluster TLS

Atualize o arquivo de configuração de cada servidor:

Altere a configuração clusterAuthX509 para corresponder ao novo certificado substituindo a configuração attributes pela configuração extensionValue .
Configure o parâmetro tlsClusterAuthX509Override para utilizar os atributos DN do certificado antigo.

Por exemplo:

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       extensionValue:  mongodb://example.mongodb.net
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDBServer }

Reiniciar membros do cluster secundário

Reinicie cada membro do cluster secundário:

Use mongosh para se conectar a cada nó do cluster secundário e, em seguida, use o método db.shutdownServer() para parar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.
Use o método rs.status() para determinar o estado membro:
```
rs.status().members
```
Aguarde o campo stateStr para este membro mostrar um valor de SECONDARY e, em seguida, reinicie o próximo secundário.

Os servidor secundários no conjunto de réplicas agora aceitam conexões de Peering de membros usando certificados com os novos valores de extensão, bem como os nome diferenciado antigos.

Reiniciar membro do cluster primário

Reinicie o membro principal:

Conecte-se ao primário usando mongosh e, em seguida, use o método rs.stepDown() para reduzir o membro como primário:
```
rs.stepDown()
```
O cluster promove um secundário com o novo certificado para servir como o novo primário.
Use o método db.shutdownServer() para desligar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.

O servidor primário no conjunto de réplicas é desativado e reiniciado como um secundário que agora aceita conexões de mesmo nível de membros usando certificados com o novo valor de extensão, bem como os atributos DN antigos.

Atualizar os certificados TLS

Atualize o arquivo de configuração de cada servidor:

Altere a configuração net.tls.certificateKeyFile para usar o novo certificado.
Altere a configuração net.tls.clusterFile para usar o novo certificado.

Por exemplo:

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server2.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster2.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       extensionValue:  mongodb://example.mongodb.net
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDB Server }

Reiniciar membros do cluster secundário

Reinicie cada membro do cluster secundário:

Use mongosh para se conectar a cada nó do cluster secundário e, em seguida, use o método db.shutdownServer() para parar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.
Use o método rs.status() para determinar o estado membro:
```
rs.status().members
```
Aguarde o campo stateStr para este membro mostrar um valor de SECONDARY e, em seguida, reinicie o próximo secundário.

Os servidores secundários no conjunto de réplicas agora usam os novos certificados x.509.

Reiniciar membro do cluster primário

Reinicie o membro principal:

Conecte-se ao primário usando mongosh e, em seguida, use o método rs.stepDown() para reduzir o membro como primário:
```
rs.stepDown()
```
O cluster promove um secundário com o novo certificado para servir como o novo primário.
Use o método db.shutdownServer() para desligar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.

O servidor primary no conjunto de réplicas é desativado e reiniciado como um secundário que usa o novo certificado x.509.

Remover a configuração de substituição de certificação nome diferenciado

Com todos os membros do cluster agora usando o novo509 certificado x., atualize o arquivo tlsClusterAuthX509Override setParameter de configuração para remover as configurações do parâmetro.

Por exemplo:

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       extensionValue:  mongodb://example.mongodb.net
security:
  clusterAuthMode: x509

Isso garante que o servidor não defina as configurações antigas do certificado na inicialização.

Reiniciar membros do cluster secundário

Reinicie cada membro do cluster secundário:

Use mongosh para se conectar a cada nó do cluster secundário e, em seguida, use o método db.shutdownServer() para parar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.
Use o método rs.status() para determinar o estado membro:
```
rs.status().members
```
Aguarde o campo stateStr para este membro mostrar um valor de SECONDARY e, em seguida, reinicie o próximo secundário.

Os servidores secundários no conjunto de réplicas são reiniciados e não aceitam mais conexões dos certificados x.509 antigos.

Reiniciar membro do cluster primário

Reinicie o membro principal:

Conecte-se ao primário usando mongosh e, em seguida, use o método rs.stepDown() para reduzir o membro como primário:
```
rs.stepDown()
```
O cluster promove um secundário com o novo certificado para servir como o novo primário.
Use o método db.shutdownServer() para desligar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.

O servidor primary é desativado e reiniciado como um secundário que não aceita mais conexões dos certificados x.509 antigos.

Saiba mais

Voltar

Rotacione x.509 com novos atributos clusterAuthX509

Exceção do Localhost