HBase
 sql >> Database >  >> NoSQL >> HBase

Apache Hadoop Ozone Security – Autenticazione

Apache Ozone è un archivio di oggetti distribuito basato sul servizio Hadoop Distributed Data Store. Può gestire miliardi di file piccoli e grandi che sono difficili da gestire da altri file system distribuiti. Ozone supporta API avanzate come Amazon S3, Kubernetes CSI e API Hadoop File System native. Ciò rende Ozone facilmente utilizzabile da diversi tipi di carichi di lavoro di big data come il data warehouse su Apache Hive, l'importazione di dati con Apache Nifi, lo streaming con Apache Spark/Flink e l'apprendimento automatico con Tensorflow.

Con la crescente impronta di dati e carichi di lavoro sfaccettati che richiedono la collaborazione tra vari gruppi, la sicurezza dei dati è della massima importanza. La sicurezza dell'ozono è stata aggiunta dal rilascio di Apache Hadoop Ozone 0.4.0 con i contributi delle comunità. È stato anche incluso come anteprima tecnologica nella versione 7.0 di CDP Data Center di Cloudera. La sicurezza può essere classificata in quattro elementi costitutivi:autenticazione, autorizzazione, controllo e crittografia. Tratteremo la parte di autenticazione in questo blog insieme al resto in quelli di follow-up.

L'autenticazione è il processo di riconoscimento dell'identità di un utente per i componenti di Ozone. Ozone è compatibile con l'architettura di sicurezza Apache Hadoop, supportando l'autenticazione avanzata tramite Kerberos e token di sicurezza.

Autenticazione basata su Kerberos

Come mostrato nella Figura 1 di seguito, i componenti del servizio inclusi OM (Gestione Ozone), SCM (Gestione contenitori di archiviazione) e Datando sono tutti autenticati tra loro tramite Kerberos. Ciascun servizio deve essere configurato con un nome principale Kerberos e un file keytab validi, che verranno utilizzati dal servizio per accedere all'avvio del servizio in modalità protetta. Maggiori dettagli sulla configurazione di OM/SCM/Datanode Kerberos possono essere trovati nei documenti Apache Hadoop Ozone. Di conseguenza, i client Ozone devono fornire un ticket Kerberos valido o token di sicurezza per accedere ai servizi Ozone come Ozone Manager per i metadati e Datanode per i blocchi di lettura/scrittura.

Token di sicurezza

Come i token di delega Hadoop, il token di sicurezza Ozone ha un identificatore di token insieme a una firma firmata dall'emittente. Il gestore di Ozone emette token di delega e token di blocco per utenti o applicazioni client autenticate con Kerberos. La firma del token può essere convalidata da validatori di token per verificare l'identità dell'emittente. In questo modo, un titolare di token valido può utilizzare il token per eseguire operazioni sui servizi cluster come se disponessero di ticket Kerberos dell'emittente.

Segnale di delega emesso da Ozone Manager consente ai titolari di token di accedere ai servizi di metadati forniti da Ozone Manager come la creazione di un volume o l'elenco degli oggetti in un bucket. Dopo aver ricevuto una richiesta da un cliente con un token di delega, il gestore di Ozone convalida il token di delega controllando la firma del firmatario tramite la sua chiave pubblica. Le operazioni sui token di delega come ottenere, rinnovare e annullare possono essere eseguite solo su una connessione autenticata Kerberos.

Blocca token sono simili ai token di delega nel senso che vengono emessi/firmati dal gestore di Ozone. Vengono emessi da Ozone manager quando una richiesta del client comporta la lettura o la scrittura di blocchi su Datanode. A differenza dei token di delega richiesti con API get/renew/cancel espliciti, vengono consegnati in modo trasparente ai client insieme alle informazioni sulla posizione della chiave/blocco. I token di blocco vengono convalidati da Datanodes quando ricevono la richiesta di lettura/scrittura dai client utilizzando la chiave pubblica del gestore di Ozone del cantante. Il token di blocco non può essere rinnovato esplicitamente dal client. Una volta scaduti, il client deve recuperare le posizioni chiave/blocco per ottenere nuovi token di blocco.

Segreto S3

Ozone supporta il protocollo Amazon S3 tramite Ozone S3 Gateway. In modalità protetta, Ozone Manager rilascia un segreto s3 per gli utenti autenticati Kerberos o le applicazioni client che accedono a Ozone utilizzando le API S3. Ne parleremo nei blog successivi su Ozone S3 Gateway.

Come funziona il token di sicurezza Ozone?

Come mostrato nella Figura 2, il token di delega e il token di blocco di Apache Hadoop tradizionali si basano su segreti condivisi tra l'emittente del token e il validatore del token per firmare e convalidare il token. Pertanto, quando l'emittente e il validatore sono diversi, ad esempio nel caso del token di blocco, la chiave master condivisa deve essere periodicamente trasferita via cavo per sincronizzarsi tra l'emittente del token (namenode) e il validatore del token (datanodes).

Invece, il token di sicurezza Ozone adotta un approccio basato su certificati. Come mostrato nella Figura 3, disaccoppia completamente gli emittenti di token ei validatori di token con una firma basata su certificato. In questo modo, i token sono più sicuri poiché i segreti condivisi non vengono mai trasportati via cavo.

In modalità protetta, SCM esegue il bootstrap come CA (Autorità di certificazione) e crea un certificato CA autofirmato. Datanode e Ozone Manager devono registrarsi con SCM CA tramite una CSR (richiesta di firma del certificato). SCM convalida l'identità di Datanode e Ozone Manager tramite Kerberos e firma il certificato del componente. I certificati firmati vengono utilizzati da Ozone Manager e Datanode per provare la propria identità. Ciò è particolarmente utile per la firma e la convalida di token di delega/token di blocco.

Nel caso del token di blocco, Ozone Manager (emittente di token) firma il token con la sua chiave privata e Datanodes (validatore di token) utilizza il certificato di Ozone Manager per convalidare i token di blocco perché sia ​​Ozone Manager che datanode si fidano dei certificati firmati da SCM CA.

Nel caso del token di delega quando Ozone Manager (sia emittente di token che validatore) è in esecuzione in modalità HA (alta disponibilità). Esistono più istanze di Ozone Manager in esecuzione contemporaneamente. Un token di delega emesso e firmato dall'istanza 1 di Ozone Manager può essere convalidato dall'istanza 2 di Ozone Manager quando il leader di Ozone Manager cambia poiché entrambe le istanze si fidano dei certificati firmati da SCM CA. Maggiori dettagli sul documento di progettazione di Ozone HA sono disponibili qui.

Conclusione

L'autenticazione è uno degli elementi costitutivi più importanti della sicurezza di Apache Hadoop Ozone. Ora dovresti avere una migliore comprensione di quali meccanismi di autenticazione sono supportati da Apache Hadoop Ozone e come funzionano. Ciò aiuterà a comprendere altri pilastri della sicurezza di Ozone come l'autorizzazione e il controllo.

Resta sintonizzato per gli articoli di follow-up su Ozone Security Authorization, Audit, Encryption e GDPR. Se sei interessato ad approfondire, puoi trovare maggiori dettagli tecnici nel documento di progettazione della sicurezza di Ozone.

Riferimento

[1] Architettura Apache Hadoop Ozone

[2] Analisi comparativa dell'ozono:lo storage di nuova generazione di Cloudera per CDP

[3] Che cos'è Kerberos? · Hadoop e Kerberos:la follia oltre il cancello

[4] Documento sull'ozono Hadoop Apache

[5] Aggiunta della sicurezza ad Apache Hadoop

[6] Documento di progettazione Apache Hadoop Ozone HA su HDDS-505.

[7] Documento di progettazione della sicurezza dell'ozono Apache Hadoop su HDDS-4.