Proteja a conexão da pesquisa ao MongoDB

Como mongot autentica em mongod

Quando mongot se conecta a mongod, ele se autentica como um cliente de banco de dados usando um dos dois modos mutuamente exclusivos:

Você pode alternar os modos depois de atualizar o recurso MongoDBSearch e permitir que o operador do Kubernetes reinicie os pods mongot. A identidade do lado mongodque o mongot autentica não precisa ser alterada se ela tiver a função necessária descrita na próxima seção.

A função mongot precisa em mongod

Qualquer que seja o modo que mongot use, a identidade que ele autentica deve ter permissão para obter dados e manter o catálogo de pesquisa em mongod. Essa identidade deve ter a função integrada searchCoordinator, que é fornecida com o MongoDB Server 8.2 e posterior e concede apenas os privilégios que o mongot exige.

Você sempre cria essa identidade; o controlador MongoDBSearch nunca a cria para você. A forma como você o cria depende se o operador Kubernetes gerencia a origem mongod:

• Fonte gerenciada pelo operador. Declare um usuário que tenha a função searchCoordinator e referencie uma senha Secret — na lista users do seu recurso MongoDBCommunity para a Community, ou como um recurso MongoDBUser separado para a empresa. O operador Kubernetes provisiona esse usuário em mongod para você. Em seguida, você referencia o mesmo usuário e Secret no recurso MongoDBSearch para que mongot possa se autenticar com ele.

• Fonte externa. Crie o usuário e conceda a ele a função searchCoordinator diretamente em sua própria implantação mongod, depois referencie suas credenciais no recurso MongoDBSearch conforme mostrado abaixo.

O restante desta página mostra como configurar cada modo de autenticação no recurso MongoDBSearch e como confiar no certificado do servidor mongod por TLS.

Configurar autenticação SCRAM

Forneça um Secret do Kubernetes que contenha a senha que mongot deve usar para autenticar no mongod. Referencie o segredo no recurso MongoDBSearch por meio de spec.source.passwordSecretRef e defina o nome de usuário por meio de spec.source.username.

spec:
  source:
    username: search-sync-source
    passwordSecretRef:
      name: my-mongot-password

O Secret referenciado deve conter a senha em uma chave chamada password por padrão. Substitua a chave por spec.source.passwordSecretRef.key se você armazenar a senha em uma chave diferente.

O usuário identificado por spec.source.username já deve existir em mongod e deve ter a função searchCoordinator. Se você omitir spec.source.username, o operador do Kubernetes assumirá que o nome de usuário é search-sync-source.

Para adicionar mTLS de camada de rede além do SCRAM, forneça um Kubernetes Secret contendo o certificado do cliente e a chave privada e faça referência a ele por meio de spec.source.tls.clientCertificateSecretRef. O Secret deve conter tls.crt e tls.key. O operador do Kubernetes apresenta este certificado durante o handshake TLS enquanto ainda autentica por meio de nome de usuário e senha.

spec:
  source:
    username: search-sync-source
    passwordSecretRef:
      name: my-mongot-password
    tls:
      clientCertificateSecretRef:
        name: my-mongot-client-cert

Se a chave privada do cliente estiver criptografada, forneça a frase secreta em um Secret separado e faça referência a ela por meio de spec.source.tls.keyFilePasswordSecretRef. O Secret deve conter a frase secreta na chave keyFilePassword.

Configurar autenticação X.509

A autenticação X.509 identifica mongot para mongod por meio de um certificado de cliente, em vez de um nome de usuário e senha. O nome diferenciado do assunto (DN) no certificado se torna a identidade de mongot em mongod.

Forneça um Secret do Kubernetes que contenha o certificado do cliente e a chave privada nas chaves tls.crt e tls.key, e faça referência a ele no recurso MongoDBSearch por meio de spec.source.x509.clientCertificateSecretRef:

spec:
  source:
    x509:
      clientCertificateSecretRef:
        name: my-mongot-x509-cert

Se a chave privada do cliente estiver criptografada, forneça a frase secreta em um Secret separado sob a chave keyFilePassword e referencie-a por meio de spec.source.x509.keyFilePasswordSecretRef:

spec:
  source:
    x509:
      clientCertificateSecretRef:
        name: my-mongot-x509-cert
      keyFilePasswordSecretRef:
        name: my-mongot-key-password

O certificado do cliente sozinho não concede acesso: mongod deve reconhecer seu nome diferenciado do assunto como uma identidade autorizada. Depois de criar o segredo do certificado acima, autorize o nome diferenciado do assunto desse certificado no mongod conforme descrito a seguir.

Confie no certificado do servidor mongod

As configurações acima estabelecem a identidade de mongot. Independentemente, quando a origem mongod usa TLS, mongot deve confiar no certificado que mongod apresenta quando mongot se conecta a ele. mongot é o cliente TLS nesta conexão; mongod apresenta seu certificado de servidor e mongot valida esse certificado em relação a uma CA que você fornece.

Quando a fonte mongod for externa ao operador Kubernetes (ou seja, declarada por meio de spec.source.external), forneça a CA que emitiu o certificado do servidor mongod:

spec:
  source:
    external:
      hostAndPorts:
        - mongod-0.example.com:27017
      tls:
        ca:
          name: my-external-mongod-ca

O campo spec.source.external.tls.ca.name faz referência a um ConfigMap do Kubernetes que contém o certificado CA na chave ca.crt. A CA deve ser aquela que emitiu o certificado do servidor mongod.

Quando a origem mongod é gerenciada pelo operador Kubernetes (por meio de spec.source.mongodbResourceRef), o operador Kubernetes lida com essa confiança de CA para você, e o campo spec.source.external.tls.ca.name não se aplica.

Rotação de certificados

mongot lê seu certificado de cliente na inicialização do processo. Para girar o certificado, atualize o Secret referenciado por spec.source.x509.clientCertificateSecretRef (para X.509) ou spec.source.tls.clientCertificateSecretRef (para mTLS sobre SCRAM) no recurso MongoDBSearch. O operador Kubernetes detecta a alteração e reinicia automaticamente os pods mongot para carregar o novo material do certificado. O mesmo se aplica à senha SCRAM Secret referenciada por spec.source.passwordSecretRef.

Para girar um certificado de cliente X.509 em MCK:

A rotação automatizada não é configurável por meio do CRD MongoDBSearch. Atualize o Secret referenciado por spec.source.x509.clientCertificateSecretRef para acionar o trigger da rotação; o operador do Kubernetes reinicia os pods automaticamente.