HBase
 sql >> база данни >  >> NoSQL >> HBase

Как да:Активирайте удостоверяване и оторизация на потребителя в Apache HBase

С конфигурацията по подразбиране на Apache HBase на всеки е разрешено да чете и да записва във всички налични в системата таблици. За много корпоративни настройки този вид политика е неприемлив.

Администраторите могат да настроят защитни стени, които решават кои машини имат право да комуникират с HBase. Въпреки това, машините, които могат да преминат защитната стена, все още имат право да четат и записват във всички таблици. Този вид механизъм е ефективен, но недостатъчен, тъй като HBase все още не може да прави разлика между множество потребители, които използват едни и същи клиентски машини, и все още няма детайлност по отношение на достъпа до таблица на HBase, семейство колони или квалификатор на колони.

В тази публикация ще обсъдим как Kerberos се използва с Hadoop и HBase за предоставяне на Удостоверяване на потребителя , и как HBase прилага Упълномощаване на потребителя да предостави на потребителите разрешения за определени действия върху определен набор от данни.

Сигурна HBase:удостоверяване и оторизация

Сигурната HBase има за цел да предпази от снифери, неудостоверени/неоторизирани потребители и мрежови атаки. Той не защитава срещу оторизирани потребители, които случайно изтриват всички данни.

HBase може да бъде конфигуриран да предоставя Удостоверяване на потребителя , което гарантира, че само оторизирани потребители могат да комуникират с HBase. Системата за упълномощаване е внедрена на ниво RPC и се основава на простия слой за удостоверяване и сигурност (SASL), който поддържа (наред с другите механизми за удостоверяване) Kerberos. SASL позволява удостоверяване, договаряне на криптиране и/или проверка на целостта на съобщението за всяка връзка (конфигурационно свойство „hbase.rpc.protection“).

Следващата стъпка след активиране Удостоверяване на потребител е да даде на администратора възможността да дефинира серия от правила за упълномощаване на потребители, които разрешават или отхвърлят определени действия. Системата за упълномощаване, известна още като копроцесор на контролера на достъп или списък за контрол на достъпа (ACL), е достъпна от HBase 0.92 (CDH4) нататък и дава възможност за дефиниране на политика за оторизация (четене/запис/създаване/администриране) с таблица/семейство /qualifier детайлност, за определен потребител.

Kerberos

Kerberos е мрежов протокол за удостоверяване. Той е проектиран да осигури силно удостоверяване за клиент/сървър приложения чрез използване на криптография със секретен ключ. Протоколът Kerberos използва силна криптография (AES, 3DES, ...), така че клиентът да може да докаже своята идентичност пред сървър (и обратно) през незащитена мрежова връзка. След като клиент и сървър са използвали Kerberos, за да докажат своята самоличност, те могат също да криптират всичките си комуникации, за да осигурят поверителността и целостта на данните, докато извършват дейността си.

Протокол за смяна на билети

На високо ниво, за да получи достъп до услуга с Kerberos, всеки клиент трябва да изпълни три стъпки:

  • Удостоверяване на Kerberos:Клиентът се удостоверява на сървъра за удостоверяване на Kerberos и получава билет за предоставяне на билети (TGT).
  • Оторизация на Kerberos:Клиентът изисква билет за услуга от сървъра за предоставяне на билети, който издава билет и ключ за сесия, ако клиентският TGT, изпратен със заявката, е валиден.
  • Заявка за услуга:Клиентът използва билета за услугата, за да се удостовери на сървъра, който предоставя услугата, която клиентът използва (напр. HDFS, HBase, …)

HBase, HDFS, ZooKeeper SASL

Тъй като HBase зависи от HDFS и ZooKeeper, защитеният HBase разчита на защитен HDFS и защитен ZooKeeper. Това означава, че сървърите на HBase трябва да създадат защитена сесия на услугата, както е описано по-горе, за да комуникират с HDFS и ZooKeeper.

Всички файлове, написани от HBase, се съхраняват в HDFS. Както при файловите системи Unix, контролът на достъпа, предоставен от HDFS, се основава на потребители, групи и разрешения. Всички файлове, създадени от HBase, имат „hbase“ като потребител, но този контрол на достъпа се основава на потребителското име, предоставено от системата, и всеки, който има достъп до машината, потенциално може да „sudo“ като потребител „hbase“. Secure HDFS добавя стъпките за удостоверяване, които гарантират, че потребителят на „hbase“ е доверен.

ZooKeeper има списък за контрол на достъпа (ACL) на всеки znode, който позволява достъп за четене/запис на потребителите въз основа на потребителска информация по подобен начин на HDFS.

HBase ACL

Сега, когато нашите потребители са удостоверени чрез Kerberos, ние сме сигурни, че потребителското име, което получихме, е един от нашите доверени потребители. Понякога това не е достатъчно детайлност – искаме да контролираме дали даден потребител може да чете или пише таблица. За да направите това, HBase предоставя механизъм за оторизация, който позволява ограничен достъп за определени потребители.

За да активирате тази функция, трябва да активирате копроцесора на Access Controller, като го добавите към hbase-site.xml под класовете копроцесор на главния и регионалния сървър. (Вижте как да настроите конфигурацията за защита на HBase тук.)

Копроцесорът е код, който се изпълнява във всеки HBase регион сървър и/или главен. Той е в състояние да прихване повечето операции (поставяне, получаване, изтриване,...) и да изпълнява произволен код преди и/или след изпълнението на операцията.

Използвайки тази способност за изпълнение на някакъв код преди всяка операция, копроцесорът на Access Controller може да провери потребителските права и да реши дали потребителят може или не може да изпълни операцията.

Обвивката на HBase има няколко команди, които позволяват на администратор да управлява потребителските права:

  • предоставяне на [таблица] [семейство] [квалификатор]
  • отменете [таблица] [семейство] [квалификатор]

Както виждате, администраторът има възможността да ограничава достъпа на потребителите въз основа на схемата на таблицата:

  • Дайте права за четене само на потребител-W на Table-X/Family-Y (предоставете 'User-W', 'R', 'Table-X', 'Family-Y' )
  • Дайте на User-W пълните права за четене/запис на Qualifier-Z (предоставете 'User-W', 'RW', 'Table-X', 'Family-Y', 'Qualifier-Z' )

Администраторът също така има възможността да предоставя глобални права, които работят на ниво клъстер, като например създаване на таблици, балансиране на региони, изключване на клъстера и т.н.:

  • Дайте на User-W възможността да създава таблици (предоставете 'User-W', 'C' )
  • Дайте на User-W възможността да управлява клъстера (предоставете 'User-W', 'A' )

Всички разрешения се съхраняват в таблица, създадена от копроцесора на Access Controller, наречена _acl_. Първичният ключ на тази таблица е името на таблицата, което сте посочили в командата grant. Таблицата _acl_ има само едно семейство колони и всеки квалификатор описва детайлността на правата за конкретна таблица/потребител. Стойността съдържа действително предоставените права.

Както можете да видите, командите на обвивката на HBase са тясно свързани с това как се съхраняват данните. Командата grant добавя или актуализира един ред, а командата revoke премахва един ред от таблицата _acl_.

Контролер за достъп под капака

Както бе споменато по-рано, копроцесорът на Access Controller използва способността да прихваща всяка потребителска заявка и да проверява  дали потребителят има права да изпълнява операциите.

За всяка операция контролерът на достъп трябва да запитва таблицата _acl_, за да види дали потребителят има права да изпълни операцията.

Тази операция обаче може да има отрицателно въздействие върху производителността. Решението за отстраняване на този проблем е използването на таблицата _acl_ за постоянство и ZooKeeper за ускоряване на търсенето на права. Всеки регионален сървър зарежда таблицата _acl_ в паметта и получава известия за промени от ZkPermissionWatcher. По този начин всеки сървър на региона има актуализираната стойност всеки път и всяка проверка на разрешенията се извършва с помощта на карта в паметта.

Пътна карта

Докато Kerberos е стабилна, добре тествана и доказана система за удостоверяване, функцията HBase ACL все още е много основна и нейната семантика все още се развива. HBASE-6096 е чадърът JIRA като справка за всички подобрения за доставка в v2 на функцията ACL.

Друга отворена тема за упълномощаване и контрол на достъпа е внедряването на система за сигурност за всеки ключ (HBASE-6222 ), което ще даде възможност да има различни стойности в една и съща клетка, свързана със защитен маркер. Това би позволило да се покаже определена част от информацията въз основа на разрешенията на потребителя.

Заключение

HBase Security добавя две допълнителни функции, които ви позволяват да защитете данните си срещу снифери или други мрежови атаки (чрез използване на Kerberos за удостоверяване на потребители и шифроване на комуникациите между услугите) и ви позволява да дефинирате правила за оторизиране на потребители, да ограничавате операциите и да ограничавате видимостта на данните за конкретни потребители.

Матео Бертоци е софтуерен инженер в Spotify и HBase консултант в Cloudera.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Оперативна база данни в CDP

  2. Честит рожден ден на Apache HBase! 10 години устойчивост, стабилност и производителност

  3. Спекулативно изпълнение в Hadoop MapReduce

  4. HDFS урок – пълно въведение в HDFS за начинаещи

  5. Създаване на Simple CRUD уеб приложение и магазин за изображения с помощта на Cloudera Operational Database и Flask