In questo precedente post del blog abbiamo fornito una panoramica di alto livello di Cloudera Replication Plugin, spiegando come porta la replica multipiattaforma con poca configurazione. In questo post, tratteremo come questo plug-in può essere applicato nei cluster CDP e spiegheremo come il plug-in consente l'autenticazione forte tra sistemi che non condividono l'attendibilità dell'autenticazione reciproca.
Utilizzo del plug-in di replica del database operativo
Il plug-in per la replica del database operativo è disponibile sia come plug-in standalone che installato automaticamente tramite Cloudera Replication Manager. Il plug-in consente ai clienti di configurare la replica quasi in tempo reale dei dati HBase dai cluster CDH/HDP/AWS EMR/Azure HDInsight a CDP Private Cloud Base e/o CDP Operational Database (COD) nel cloud pubblico. Viene inoltre distribuito automaticamente quando si utilizza Cloudera Replication Manager per impostare la replica tra CDP Private Cloud Base e COD o tra istanze COD nel cloud pubblico. Cloudera Replication Manager consente inoltre di combinare la funzionalità snapshot HBase con questo plug-in per gestire anche la replica di dati preesistenti in un'unica configurazione.
Per le istruzioni di installazione, fare riferimento a Politica di replica HBase argomento su Gestione repliche documentazione ufficiale.
Per le versioni CDH/HDP legacy, il plug-in viene fornito come pacchetto da installare solo nel cluster legacy.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x e 6.x
Il pacchetto ha la versione bloccata con i binari specifici della versione. Per ciascuna delle versioni sopra menzionate, dovrebbe essere acquisito per cluster. Contatta il tuo team di vendita Cloudera se sei interessato a ottenerne uno.
Dettagli di implementazione
L'impedimento risolto da Operational Database Replication Plugin è l'autenticazione reciproca tra cluster in diverse configurazioni di sicurezza. Ricordando questo post del blog precedente, la replica predefinita di HBase richiede che entrambi i cluster non siano configurati per la sicurezza o che siano entrambi configurati con la sicurezza. In quest'ultimo caso, entrambi i cluster devono trovarsi nello stesso reame kerberos o avere l'autenticazione cross-reame impostata sul sistema kerberos. Questa sarebbe una sfida aggiuntiva nel contesto di CDP, in cui ogni ambiente viene eseguito in un ambito di sicurezza autonomo. Per capirlo in modo più dettagliato, dobbiamo esaminare come viene implementata la sicurezza di Apache HBase.
Utilizzo di SASL per creare fiducia
Nella replica HBase, i RegionServer nel cluster di origine contattano i RegionServer nel cluster di destinazione tramite connessioni RPC. Quando la sicurezza è abilitata, l'autenticazione viene eseguita nella fase di creazione della connessione RPC utilizzando il framework Simple Authentication and Security Layer (SASL). HBase fornisce già il seguente integrato Autenticazione SASL meccanismi:kerberos, digest e semplice. Quando kerberos è abilitato, le credenziali del cluster di origine saranno attese dal cluster di destinazione, che quindi convaliderà queste credenziali rispetto al proprio KDC, utilizzando kerberos SASL meccanismo. Questo si basa su kerberos GSSAPI implementazione per l'autenticazione delle credenziali fornite rispetto al KDC del cluster di destinazione, pertanto l'attendibilità per l'entità del cluster di origine deve essere stata implementata a livello di sistema kerberos, disponendo entrambe le credenziali del cluster nello stesso ambito o facendo in modo che il KDC del cluster di destinazione consideri attendibili le credenziali da cluster di origine (un approccio comunemente noto come cross-realm autenticazione).
Estensione dell'autenticazione SASL HBase
Fortunatamente, SASL è progettato per consentire implementazioni di autenticazione personalizzate. Ciò significa che potrebbe essere progettata una soluzione basata su SASL, se un meccanismo SASL aggiuntivo potesse essere inserito nell'insieme delle opzioni integrate sopra menzionate. A tal fine, Cloudera ha proposto un refactoring del livello RPC di HBase, che è stato rivisto e accettato dalla comunità Apache HBase in HBASE-23347 .
Meccanismo SASL collegabile
Con le modifiche introdotte da HBASE-23347 , è possibile definire ulteriori meccanismi di autenticazione SASL tramite la configurazione HBase per essere utilizzati dal livello RPC. Le connessioni RPC in ingresso definiscono il tipo SASL specifico nell'intestazione, quindi il server RPC seleziona l'implementazione specifica per eseguire l'autenticazione effettiva:
Plugin di replica del database operativo implementa il suo meccanismo SASL personalizzato, consentendo ai cluster su diversi reami kerberos di comunicare con sforzi di configurazione senza interruzioni (senza la necessità di regni incrociati kerberos ). Estende la replica HBase in modo che l'origine crei un token SASL di Plugin di replica tipo personalizzato, con le credenziali di un utente macchina predefinito nel cluster COD di destinazione. Questo tipo di utente può essere facilmente creato da Cloudera Management Console Interfaccia utente, e quindi propagato all'autorità di autenticazione Kerberos sottostante del cluster COD. Istruzioni dettagliate sulla creazione di utenti di macchine di replica sono trattate nella sezione dei passaggi prerequisiti della documentazione di Cloudera Replication Manager.
Quando il server RPC nella destinazione legge il token e lo identifica è un Plugin di replica tipo, le credenziali correlate vengono analizzate dal token e utilizzate per l'autenticazione.
Plugin di replica del database operativo utilizza l'autenticazione PAM per convalidare le credenziali utente della macchina. I cluster COD vengono sempre forniti con l'autenticazione PAM rispetto al dominio di sicurezza FreeIPA dell'ambiente CDP.
Protezione delle credenziali utente della macchina
Un problema critico in questa soluzione è che il cluster di origine deve ottenere le credenziali dall'utente della macchina del cluster di destinazione. Per ovvi motivi, questo non dovrebbe essere esposto in alcun modo sulla configurazione di origine. Queste credenziali vengono inviate anche via cavo nel token SASL all'interno della connessione RPC, quindi devono essere crittografate prima della trasmissione. Il plug-in di replica fornisce il proprio strumento per generare un jceks file che memorizza le credenziali utente della macchina, crittografato. Una volta creato questo file, deve essere copiato in entrambi i cluster e reso leggibile da hbase solo utente. Il diagramma seguente mostra una panoramica della distribuzione del plug-in di replica del database operativo componenti che si integrano alle classi di replica HBase standard nel contesto di RegionServers. Le caselle rosa rappresentano il codice di replica e connessione RPC già fornito da HBase, mentre le caselle gialle mostrano lo strato di astrazione introdotto all'interno di HBASE-23347. Infine, le classi arancioni evidenziano gli artefatti rilevanti che implementano il Plugin di replica del database operativo logica.
Conclusione
La replica è uno strumento prezioso per l'implementazione di soluzioni di migrazione DR e DC per HBase. Ha alcuni avvertimenti, come mostrato qui, quando si ha a che fare con le configurazioni di sicurezza dei cluster. Tuttavia, la capacità di migrare i dati dalle attuali distribuzioni "on-prem" ai cluster CDP sul cloud è fondamentale. Plugin di replica del database operativo Cloudera offre flessibilità durante l'integrazione di cluster protetti, insieme a una migliore manutenibilità per questa integrazione di sicurezza, poiché è interamente implementata a livello HBase, in contrasto con kerberos cross-realm, che richiede modifiche alla definizione del sistema kerberos, spesso responsabilità di un team completamente diverso, con le proprie politiche restrittive.
Prova il modello Database operativo in Piattaforma dati Cloudera (CDP)!
