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

Налагане на контроли за достъп, базирани на роли, с ClusterControl

В скорошната версия на Severalnines на ClusterControl версия 1.8.2 въведохме много сложни функции и промени. Една от важните характеристики е наскоро подобрената система за управление на потребители, която обхваща управление на нови потребители и LDAP. Допълнителна съществуваща възможност в ClusterControl е неговият контрол на достъпа, базиран на роли (RBAC) за управление на потребители, което е фокусът на този блог.

Контрол на достъп, базиран на роли в ClusterControl

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

Контролът на достъп, базиран на роли в ClusterControl, играе важна роля, особено за администраторски потребители, които постоянно го използват като част от своите DBA задачи. DBA на ClusterControl трябва да е запознат с тази функция, тъй като позволява на DBA да делегира задачи на членовете на екипа, да контролира достъпа до функционалността на ClusterControl и да не излага всички функции и функционалности на всички потребители. Това може да се постигне чрез използване на функционалността за управление на потребителите, която ви позволява да контролирате кой какво може да прави. Например можете да настроите екип като анализатор, devops или DBA и да добавите ограничения според техния обхват на отговорности за  даден клъстер от база данни.

Контролът за достъп до ClusterControl е изобразен на  следната диаграма,

По-долу са предоставени подробности за използваните по-горе термини. Екип може да бъде назначен към един или повече от клъстерите на базата данни, управлявани от ClusterControl. Екипът се състои от празни или множество потребители в екип. По подразбиране, когато създавате нов екип, акаунтът на супер администратор винаги ще бъде свързан с него. Изтриването на суперадминистратора не го лишава от връзката с този нов екип.

Потребител и клъстер трябва да бъдат присвоени към екип; това е задължителна реализация в ClusterControl. По подразбиране суперадминистративният акаунт е определен за администраторски екип, който вече е създаден по подразбиране. По подразбиране клъстерите от бази данни също се присвояват на администраторския екип.

За една роля може да не е назначен потребител или може да бъде присвоена на множество потребители в съответствие с тяхната роля в ClusterControl.

Роли в ClusterControl

Ролите в ClusterControl всъщност са зададени по подразбиране. Следват следните роли по подразбиране:

  • Супер администратор - Това е скрита роля, но е ролята на супер администратор (суперадмин), което означава всички функции са налични за тази роля. По подразбиране потребителят, който сте създали след успешна инсталация, представлява вашата роля на супер администратор. Освен това, когато създавате нов екип, суперадминистраторът винаги се присвоява на новия екип по подразбиране.

  • Администратор – По подразбиране почти всички функции са видими. Да бъдеш видим означава, че потребителите с ролята на администратор могат да изпълняват задачи за управление. Функциите, които не са налични за тази роля, са съветникът на клиентите и управлението на SSL ключовете.

  • Потребител - Интеграции, достъп до всички клъстери и някои функции не са налични за тази роля и са отказани от по подразбиране. Това е полезно, ако искате да зададете редовни потребители, които не са предназначени за работа с база данни или административни задачи. Трябва да се направят някои ръчни стъпки, за да могат тези в ролята на потребител да видят други клъстери.

Ролите в ClusterControl са произволни, така че администраторите могат да създават произволни роли и да ги присвояват на потребител под Teams.

Как да влезете в ролите на ClusterControl

Можете да създадете персонализирана роля със собствен набор от нива на достъп. Задайте ролята на конкретен потребител в раздела Teams. Това може да бъде постигнато, като намерите управление на потребителите в страничната лента в десния ъгъл. Вижте екранната снимка по-долу:

Прилагане на контроли за достъп, базирани на роли с ClusterControl

Прилагането на RBAC е специфично за домейна на потребителя, което ограничава достъпа на потребителя до функциите на ClusterControl в съответствие с техните роли и привилегии. Имайки това предвид,  трябва да започнем да създаваме конкретен потребител.

Създаване на потребител в ClusterControl

За да създадете потребител, започнете от раздела Управление на потребителите ➝ Екипи. Сега нека първо създадем екип.

Веднъж създаден, има суперадминистраторски акаунт, който се свързва по подразбиране, след като се създаде екип.

Сега нека добавим нов потребител. Добавянето на нов потребител трябва да се извърши под екип, за да можем да го създадем под DevOps.

Както може би сте забелязали, новият потребител, който създадохме, вече е под ролята Потребител, която се добавя по подразбиране в ClusterControl. Тогава екипът също е под DevOps.

По принцип сега има двама потребители в екипа на DevOps, както е показано по-долу:

Обърнете внимание, че ролите са специфични за домейна на потребителя, така че прилага ограничения за достъп само към този конкретен потребител, а не към екипа, към който принадлежи.

Администратор срещу потребителски роли (роли по подразбиране в ClusterControl)

Тъй като имаме две роли, добавени по подразбиране в ClusterControl, има ограничения, които са зададени по подразбиране. За да разберете какво представляват това, просто отидете на  Управление на потребителите ➝ Контрол на достъпа. По-долу е екранна снимка, която изобразява наличните функции или привилегии, които може да прави потребител, който принадлежи към ролята:

Роля на администратор

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

Ролята на администратор има много повече привилегии, докато ролята на потребител има някои привилегии, които са ограничени. Тези роли по подразбиране могат да бъдат променени в съответствие с желаната от вас конфигурация. Добавянето на роля също ви позволява да стартирате и да зададете кои роли са разрешени или не. Например, ще създадем нова роля. За да създадете роля, просто натиснете бутона "+" покрай ролите. Можете да видите новата роля, която създадохме, наречена Viewer.

Всички отметки са премахнати. Просто поставете отметка в колоната Разрешаване, за да активирате функцията или привилегията, или отметнете под колоната Отказ, ако искате да откажете достъп. Колоната Управление позволява на потребителите в тази роля да изпълняват задачи за управление. Докато колоната Modify ви позволява да активирате модификации, които са достъпни само за привилегии или функции в Alarms, Jobs и Settings.

Тестване на RBAC

В този пример следните клъстери присъстват в моя контролер, както е показано по-долу:

Това се вижда от акаунта на супер администратор в тази среда.

Сега, когато имаме зададен RBAC за потребителя, който току-що създадохме, нека се опитаме да влезем с помощта на имейла и паролата, които току-що зададохме.

Това е създадено,

Няма налични и видими клъстери и някои привилегии са отказани, както е показано по-долу, като настройки за управление на ключове и известия по имейл:

Коригиране на RBAC

Тъй като привилегиите в ролите са променливи, е лесно да ги управлявате чрез Управление на потребителите ➝ Контрол на достъпа.

Сега нека позволим на създадения потребител да види клъстер. Тъй като на нашия потребител е отказан достъп до всички клъстери, трябва да го активираме. Вижте по-долу,

Сега, както казахме по-рано въз основа на диаграмата, клъстерите се контролират от екипа. Например, има следните назначения на клъстер,  по-долу:

Тъй като трябва да присвоим клъстера към правилния екип, избирането на конкретния клъстер и щракването върху бутона „Промяна на екипа“ ще покаже подкана, което ви позволява да го пренасочите към правилния екип.

Сега нека го присвоим на DevOps.

Сега влезте отново като новосъздадения потребител и ще можем да видим клъстера.

Резюме

Контрол на достъп, базиран на роли (RBAC) в ClusterControl е функция, която осигурява фин ограничителен контрол на достъпа за всеки потребител, който сте създали в ClusterControl, позволявайки по-голяма сигурност и по-рестриктивен контрол на достъпа въз основа на ролята на потребителя.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. MongoDB $pull масив 2 ниво

  2. Усъвършенстване на изкуството за автоматизиране и управление на най-популярните бази данни с отворен код:2017 @ Severalnines

  3. Възел - Mongoose 3.6 - Заявка за сортиране с попълнено поле

  4. Изпълнете mongodb shell скрипт чрез C# драйвер

  5. В Mongo каква е разликата между разделяне и репликация?