Autenticación interna/de membresía autogestionada

Requisitos clave

La longitud de una clave debe estar entre 6 y 1024 caracteres y solo puede contener caracteres del conjunto base64. MongoDB elimina los espacios en blanco (p. ej., x0d, x09 y x20) para mayor comodidad entre plataformas. Como resultado, las siguientes operaciones generan claves idénticas:

echo -e "mysecretkey" > key1
echo -e "my secret key" > key1
echo -e "my secret key\n" > key2
echo -e "my    secret    key" > key3
echo -e "my\r\nsecret\r\nkey\r\n" > key4

Formato de archivo de claves

Los archivos de claves para la autenticación de membresía interna utilizan el formato YAML para permitir múltiples claves en un archivo de claves. El formato YAML acepta:

• Una string de clave única (igual que en versiones anteriores)

• Una secuencia de cadenas clave

El formato YAML es compatible con los archivos de claves de una sola clave existentes que utilizan el formato de archivo de texto.

Por ejemplo,

my old secret key1

- my old secret key1
- my new secret key2

La posibilidad de especificar varias claves en un archivo permite su actualización gradual sin tiempo de inactividad.Consulte Rotar claves para conjuntos de réplicas autogestionados y Rotar claves para clústeres fragmentados autogestionados.

Todas mongod las mongos instancias y de una implementación deben compartir al menos una clave común.

En los sistemas UNIX, el archivo de claves no debe tener permisos de grupo ni de otros. En los sistemas Windows, no se verifican los permisos de los archivos de claves.

Debe almacenar el archivo de clave en cada servidor que aloje al miembro del conjunto de réplicas o clústeres fragmentados.

Configuración de MongoDB para archivo de claves

Para especificar el archivo de claves, utilice la configuración o security.keyFile la --keyFile opción de línea de comando.

Para obtener un ejemplo de autenticación interna de archivo de claves, consulte Actualizar el conjunto de réplicas autoadministradas a autenticación de archivo de claves.

Requisitos del certificado de nodo

Los certificados de miembro que utiliza para verificar la membresía a un clúster fragmentado o un conjunto de réplicas (, sinet.tls.clusterFile net.tls.certificateKeyFile se especifica, y), deben tener las siguientes propiedades:

• Una única autoridad de certificación (CA) debe emitir todos los certificados x.509 para los miembros de un clúster fragmentado o un conjunto de réplicas.

• El nombre distinguidoDN (), que se encuentra en el del certificado de subject miembro, debe especificar un valor no vacío para al menos uno de los siguientes atributos:

  • la organización (O)

  • la Unidad Organizativa (OU)

  • El componente del dominio (DC)

• Los atributos de la organización (), los atributos de la unidad organizativaOOU () y los componentes del dominioDC () deben coincidir con los de los net.tls.clusterFile certificados y de los otros net.tls.certificateKeyFile tlsX509ClusterAuthDNOverride miembros del clúster (o el valor, si está configurado).

  Para que coincida, el certificado debe cumplir todas las especificaciones de estos atributos, incluso si no se especifican. El orden de los atributos es irrelevante.

  En el siguiente ejemplo, los dos DN contienen especificaciones coincidentes para O, OU, así como la no especificación del atributo DC.

  CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
  C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

  Sin embargo, los dos DN siguientes contienen una falta de coincidencia para el atributo OU ya que uno contiene dos especificaciones OU y el otro, solo una.

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• En implementaciones multiclúster, cada clúster debe usar un509 certificado miembro X. diferente. Cada certificado debe tener valores únicos en los campos de nombre distintivo O OU DC (DN), y.

  Si dos clústeres tienen certificados con los mismos valores DN, un servidor comprometido en un clúster puede autenticarse como miembro del otro.

• El nombre común (CN) o una de las entradas del nombre alternativo del sujeto (SAN) deben coincidir con el nombre de host del servidor de los demás miembros del clúster. A partir de MongoDB 4.2, al comparar SAN, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo comparaba nombres DNS.

  Por ejemplo, los certificados de un clúster podrían tener los siguientes temas:

  subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US

• Si el certificado utilizado como certificateKeyFile incluye extendedKeyUsage, el valor debe incluir clientAuth ("Autenticación de cliente web TLS") y serverAuth ("Autenticación de servidor web TLS").

  extendedKeyUsage = clientAuth, serverAuth

• Si el certificado utilizado como clusterFile incluye extendedKeyUsage, el valor debe incluir clientAuth.

  extendedKeyUsage = clientAuth

• El certificado509 x. no debe estar vencido.

  mongod / registra una advertencia en la conexión si mongos el509 certificado x. presentado caduca dentro de los 30 días posteriores a la hora del mongod/mongos sistema host.

Configuración de MongoDB

Se puede usar TLS para la autenticación interna entre cada miembro del set de réplicas (cada instancia mongod) o de un clúster particionado (cada instancia mongod y mongos).

Para utilizar TLS para la autenticación interna, utiliza la siguiente configuración:

• security.clusterAuthMode o --clusterAuthMode configurado para x509

• net.tls.clusterFile or --tlsClusterFile

mongod Las mongos instancias y usan su archivo de clave de certificado para demostrar su identidad a los clientes, pero también pueden usarse para la autenticación de miembros. Si no especifica un archivo de clúster, los miembros usan sus archivos de clave de certificado para la autenticación de miembros. Especifique el archivo de clave de certificado con net.tls.certificateKeyFile o.--tlsCertificateKeyFile

Para utilizar tanto para la autenticación del cliente como para la autenticación de membresía, el certificado certificate key file debe:

• Omite extendedKeyUsage o

• Especifica extendedKeyUsage = serverAuth, clientAuth