Apache Ozone es un almacén de objetos distribuidos creado sobre el servicio de almacenamiento de datos distribuidos de Hadoop. Puede administrar miles de millones de archivos pequeños y grandes que son difíciles de manejar con otros sistemas de archivos distribuidos. Ozone es compatible con API enriquecidas como Amazon S3, Kubernetes CSI, así como API nativas del sistema de archivos de Hadoop. Esto hace que Ozone sea fácilmente consumible por diferentes tipos de grandes cargas de trabajo de datos, como el almacenamiento de datos en Apache Hive, la ingesta de datos con Apache Nifi, la transmisión con Apache Spark/Flink y el aprendizaje automático con Tensorflow.
Con la huella de datos cada vez mayor y las cargas de trabajo multifacéticas que necesitan la colaboración entre varios grupos, la seguridad de los datos es de suma importancia. La seguridad de ozono se ha agregado desde el lanzamiento de Apache Hadoop Ozone 0.4.0 con contribuciones de las comunidades. También se ha incluido como avance tecnológico en la versión CDP Data Center 7.0 de Cloudera. La seguridad se puede clasificar en cuatro bloques de construcción:autenticación, autorización, auditoría y cifrado. Cubriremos la parte de Autenticación en este blog junto con el resto en los siguientes.
La autenticación es el proceso de reconocer la identidad de un usuario para los componentes de Ozone. Ozone es compatible con la arquitectura de seguridad de Apache Hadoop y admite una fuerte autenticación mediante Kerberos y tokens de seguridad.
Autenticación basada en Kerberos
Como se muestra en la Figura 1 a continuación, los componentes del servicio, incluidos OM (Ozone Manager), SCM (Storage Container Manager) y Datandoes, se autentican entre sí a través de Kerberos. Cada servicio debe configurarse con un nombre principal de Kerberos y un archivo keytab válidos, que el servicio utilizará para iniciar sesión al iniciarse en modo seguro. Se pueden encontrar más detalles sobre la configuración de OM/SCM/Datanode Kerberos en los documentos de Apache Hadoop Ozone. En consecuencia, los clientes de Ozone deben proporcionar un ticket de Kerberos válido o tokens de seguridad para acceder a los servicios de Ozone, como Ozone Manager para metadatos y Datanode para bloques de lectura/escritura.
Fichas de seguridad
Al igual que los tokens de delegación de Hadoop, el token de seguridad de Ozone tiene un identificador de token junto con una firma firmada por el emisor. Ozone Manager emite tokens de delegación y tokens de bloqueo para usuarios o aplicaciones cliente autenticadas con Kerberos. La firma del token puede ser validada por validadores de tokens para verificar la identidad del emisor. De esta forma, un titular de token válido puede utilizar el token para realizar operaciones contra los servicios de clúster como si tuviera tickets de Kerberos del emisor.
Token de delegación emitido por Ozone Manager permite a los titulares de tokens acceder a los servicios de metadatos proporcionados por Ozone Manager, como crear un volumen o enumerar los objetos en un depósito. Al recibir una solicitud de un cliente con un token de delegación, el administrador de Ozone valida el token de delegación al verificar la firma del firmante a través de su clave pública. Las operaciones de token de delegación, como obtener, renovar y cancelar, solo se pueden realizar a través de una conexión autenticada de Kerberos.
Fichas de bloque son similares a los tokens de delegación en el sentido de que son emitidos/firmados por el administrador de Ozone. Son emitidos por el administrador de ozono cuando una solicitud de cliente implica lectura o escritura de bloques en Datanode. A diferencia de los tokens de delegación solicitados con API explícitas para obtener/renovar/cancelar, se entregan de manera transparente a los clientes junto con la información de ubicación de clave/bloque. Los tokens de bloque son validados por Datanodes cuando reciben la solicitud de lectura/escritura de los clientes que utilizan la clave pública del administrador de Singer Ozone. El token de bloque no puede ser renovado explícitamente por el cliente. Una vez vencido, el cliente debe volver a buscar las ubicaciones de clave/bloque para obtener nuevos tokens de bloque.
Secreto S3
Ozone es compatible con el protocolo Amazon S3 a través de Ozone S3 Gateway. En el modo seguro, Ozone Manager emite un secreto s3 para los usuarios autenticados de Kerberos o las aplicaciones cliente que acceden a Ozone mediante las API de S3. Cubriremos eso en blogs posteriores sobre Ozone S3 Gateway.
¿Cómo funciona el token de seguridad de ozono?
Como se muestra en la Figura 2, el token de delegación y el token de bloque tradicionales de Apache Hadoop se basan en secretos compartidos entre el emisor del token y el validador del token para firmar y validar el token. Por lo tanto, cuando el emisor y el validador son diferentes, por ejemplo, en el caso del token de bloque, la clave maestra compartida debe transferirse periódicamente por cable para sincronizar entre el emisor del token (nodo de nombre) y el validador del token (nodos de datos).
En cambio, el token de seguridad de Ozone adopta un enfoque basado en certificados. Como se muestra en la Figura 3, desacopla por completo a los emisores de tokens y los validadores de tokens con una firma basada en certificados. De esta manera, los tokens son más seguros ya que los secretos compartidos nunca se transportan por cable.
En el modo seguro, SCM se autoarranca como una CA (autoridad de certificación) y crea un certificado de CA autofirmado. Datanode y Ozone Manager deben registrarse con SCM CA a través de un CSR (solicitud de firma de certificado). SCM valida la identidad de Datanode y Ozone Manager a través de Kerberos y firma el certificado del componente. Los certificados firmados son utilizados por Ozone Manager y Datanode para probar su identidad. Esto es especialmente útil para la firma y validación de token de delegación/token de bloque.
En el caso del token de bloque, Ozone Manager (emisor de tokens) firma el token con su clave privada y Datanodes (validador de tokens) usa el certificado de Ozone Manager para validar tokens de bloque porque tanto Ozone Manager como datanode confían en los certificados firmados por SCM CA.
En el caso del token de delegación cuando Ozone Manager (tanto el emisor como el validador del token) se ejecuta en modo HA (alta disponibilidad). Hay varias instancias de Ozone Manager ejecutándose simultáneamente. Un token de delegación emitido y firmado por la instancia 1 de Ozone Manager puede ser validado por la instancia 2 de Ozone Manager cuando el Ozone Manager líder cambia, ya que ambas instancias confían en los certificados firmados por SCM CA. Puede encontrar más detalles del documento de diseño de Ozone HA aquí.
Conclusión
La autenticación es uno de los componentes básicos más importantes de la seguridad de Apache Hadoop Ozone. Ahora debería comprender mejor qué mecanismos de autenticación son compatibles con Apache Hadoop Ozone y cómo funcionan. Esto ayudará a comprender otros pilares de la seguridad de Ozone, como la autorización y la auditoría.
Estén atentos a los artículos de seguimiento sobre Autorización, Auditoría, Cifrado y RGPD de Seguridad de Ozono. Si está interesado en profundizar, puede encontrar más detalles técnicos en el documento de diseño de seguridad de Ozone.
Referencia
[1] Arquitectura de ozono de Apache Hadoop
[2] Benchmarking Ozone:almacenamiento de próxima generación de Cloudera para CDP
[3] ¿Qué es Kerberos? · Hadoop y Kerberos:La locura más allá de la puerta
[4] Documento Apache Hadoop Ozone
[5] Adición de seguridad a Apache Hadoop
[6] Documento de diseño de alta disponibilidad de Apache Hadoop Ozone en HDDS-505.
[7] Documento de diseño de seguridad de Apache Hadoop Ozone en HDDS-4.
