Hadoop-sikkerhetsprosjektet kalt Ranger ble angivelig kalt til hyllest til Chuck Norris i rollen "Walker, Texas Ranger". Prosjektet har sine røtter i XA Secure, som ble kjøpt opp av Hortonworks, som deretter ble omdøpt til Argus før de slo seg ned i Apache Software Foundation som Ranger.
Da Hadoop startet, var det et sett med løst koblede deler som hovedsakelig ble brukt i bakenden av de store internettbedriftene som Yahoo. Disse delene ble pakket inn i distribusjoner og markedsført som Hadoop av slike som MapR, Cloudera og Hortonworks.
En slik bitvis arkitektur er ikke uvanlig i åpen kildekode eller til og med i den brede verden av kommersiell programvare. Det fører imidlertid til sikkerhetsutfordringer. Noen vil lese dette som "det er usikkert", men det er ikke nødvendigvis tilfelle - selv om det kan være. Problemet er mer hvordan autentiserer du brukere til alle deler av dette delesystemet - og når du autentiserer dem, hvordan autoriserer du dem til å gjøre bare det du mener for å tillate dem å gjøre?
Hver del av Hadoop har sin egen LDAP- og Kerberos-autentisering, så vel som sine egne midler og regler for autorisasjon (og i de fleste tilfeller helt separate implementeringer av det samme). Dette betyr at du må konfigurere Kerberos eller LDAP til hver enkelt del, og deretter definere disse reglene i hver separate konfigurasjon. Det Apache Ranger gjør er å tilby en plugin-modul til hver av disse delene av Hadoop og et felles autentiseringslager, samt at du kan definere policyer på et sentralisert sted.
Ranger er helt klart et Hortonworks-sponset prosjekt (i motsetning til en Cloudera eller MapR eller nå Databricks). Du kan fortelle dette delvis ved hvordan det er skinnet (grønt) og delvis på grunn av hva det støtter. For tiden støtter Ranger følgende:
- HDFS
- Hive
- Storm
- HBase
- Knox
- GARN
- Kafka
- Solr
Bortsett fra HDFS og HBase, som støttes som en del av kjernen til Hadoop og Solr, er dette noen av de mer "Hortonworksy" -prosjektene. I en moderne distribusjon vil du sannsynligvis se andre komponenter, for eksempel Spark eller muligens Impala (fra Cloudera). Ikke desto mindre er Ranger en flott ting.
Hvordan Ranger fungerer
I Ranger jobber du for hver komponent med et arkiv. Disse depotene er basert på en underliggende plugin-modul eller agent som fungerer med den komponenten.
Knyttet til hvert av disse arkivene er et sett med policyer som er knyttet til ressursen du beskytter (en tabell, mappe eller kolonne) og en gruppe (for eksempel administratorer) og hva de har lov til å gjøre med den tingen (les , skriv og så videre). Du gir hvert policy et navn - si: "Bare grp_nixon kan lese apac_china-tabellen."
En brukergrensesnitt med et sentralt syn på hvem som har lov til å gjøre det som bringer sårt tiltrengt enkelhet til Hadoop-økosystemet, men det er ikke alt Ranger tilbyr. Det gir også revisjonslogging. Selv om dette ikke kan erstatte all loggføring av applikasjoner du noen gang kan ønske deg, hvis du bare trenger å vite hvem som har tilgang til hva på HDFS eller hvilke retningslinjer som ble håndhevet hvor, er det sannsynligvis akkurat det du trenger.
I tillegg kan Ranger tilby Key Management Services for å jobbe med HDFSs nye TDE (gjennomsiktig datakryptering). Så hvis du trenger end-to-end-kryptering og en ren måte å administrere nøklene knyttet til den, er Ranger ikke et dårlig sted å starte.
Ranger ser fremover
Jeg tror det største håpet for Ranger kommer fra utvidbarheten. Du kan lage dine egne plugin-moduler for områder som ikke er dekket.
Hvis du håpet at dette var slutten på historien om Hadoop-sikkerhet, har Cloudera dessverre sitt eget Apache-prosjekt kalt Sentry (som MapR ser ut til å også støtte) som dekker omtrent det samme området. For å være rettferdig var Sentry først, deretter kjøpte Hortonworks XA Secure. Når det er sagt, er dokumentasjonen for Sentry praktisk talt ikke eksisterende, dekningen er mer begrenset, og prosjektnettstedet er i forfall (selv om aktivitet på GitHub nylig tok seg opp).
Hadoop-sikkerhet har kommet langt. Ranger gir en ganske omfattende, om ennå litt ufullstendig måte å administrere økosystemet på. Hullene som vedvarer skyldes hovedsakelig leverandørkonkurranse i hele big data-verdenen. Disse kan fylles ut via prosjektets utvidbarhet, men det ville være hyggelig å se mer samarbeid og fellesskap i Apache-verdenen.
