MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Управление на нови потребители и LDAP в ClusterControl 1.8.2

След надграждане до ClusterControl 1.8.2, трябва да получите следния банер за известие:

Какво става с това? Това е известие за амортизация на текущата система за управление на потребителите в полза на новата система за управление на потребителите, управлявана от услугата ClusterControl на контролера (cmon). Когато щракнете върху банера, ще бъдете пренасочени към страницата за създаване на потребител, за да създадете нов потребител с администратор, както е описано в това ръководство за потребителя.

В тази публикация в блога ще разгледаме новата система за управление на потребителите, въведена в ClusterControl 1.8.2, и ще видим как тя се различава от предишните. Само за пояснение, старата система за управление на потребителите ще продължи да работи успоредно с новата система за удостоверяване и управление на потребители до Q1 2022 г. Отсега нататък всички нови инсталации за ClusterControl 1.8.2 и по-нови ще бъдат конфигурирани с новия потребител система за управление.

Управление на потребителите преди 1.8.2

ClusterControl 1.8.1 и по-стари съхранява информацията за потребителя и счетоводството в база данни за уеб потребителски интерфейс, наречена "dcps". Тази база данни е независима от базата данни cmon, която се използва от услугата ClusterControl Controller (cmon).

Потребителски акаунти и удостоверяване

Потребителският акаунт се състои от следната информация:

  • Име

  • Часова зона

  • Имейл (използван за удостоверяване)

  • Парола

  • Роля

  • Екип

Човек ще използва имейл адрес за влизане в ClusterControl GUI, както е показано на следната екранна снимка:

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

Разрешения и контрол на достъп

ClusterControl 1.8.1 и по-стари използваха базиран на потребителски интерфейс контрол на достъп въз основа на присвояване на роля. С друг термин ние нарекохме този контрол на достъпа, базиран на роли (RBAC). Администраторът ще създаде роли и на всяка роля ще бъде присвоен набор от разрешения за достъп до определени функции и страници. Прилагането на ролята се случва от предния край, където услугата на контролера ClusterControl (cmon) няма представа дали активният потребител има възможност за достъп до функционалността, тъй като информацията никога не се споделя между тези две машини за удостоверяване. Това би направило удостоверяването и упълномощаването по-трудни за контролиране в бъдеще, особено при добавяне на повече функции, съвместими както с GUI, така и с CLI интерфейса.

Следната екранна снимка показва наличните функции, които могат да се контролират чрез RBAC:

Администраторът просто трябва да избере съответното ниво на достъп за конкретни функции и то ще бъде съхранено в базата данни "dcps" и след това ще се използва от ClusterControl GUI, за да разреши ресурси на потребителския интерфейс на потребителите на GUI. Създаденият тук списък за достъп няма нищо общо с потребителите на CLI.

LDAP

ClusterControl преди 1.8.1 използва PHP LDAP модула за LDAP удостоверяване. Той поддържа Active Directory, OpenLDAP и FreeIPA директорийни услуги, но само ограничен брой LDAP атрибути могат да се използват за идентификация на потребителя, като uid, cn или sAMAccountName. Внедряването е доста просто и не поддържа разширено базово филтриране на потребители/групи, съпоставяне на атрибути и TLS реализация.

По-долу е необходимата информация за настройките на LDAP:

Тъй като това е интерфейсна услуга, лог файлът на LDAP се съхранява под директория на уеб приложения, по-специално в /var/www/html/clustercontrol/app/log/cc-ldap.log. Удостоверен потребител ще бъде съпоставен с конкретна роля и екип на ClusterControl, както е дефинирано в страницата за съпоставяне на LDAP групата.

Управление на потребителите след 1.8.2

В тази нова версия ClusterControl поддържа както манипулатори за удостоверяване, удостоверяване на предния интерфейс (използвайки имейл адрес) и удостоверяване на бекенда (използвайки потребителско име). За удостоверяването на бекенда ClusterControl съхранява потребителската информация и счетоводството в базата данни cmon, която се използва от услугата ClusterControl Controller (cmon).

Потребителски акаунти и удостоверяване

Потребителският акаунт се състои от следната информация:

  • Потребителско име (използва се за удостоверяване)

  • Имейл адрес

  • Пълно име

  • Етикети

  • Произход

  • Деактивирано

  • Спиране

  • Групи

  • Собственик

  • ACL

  • Неуспешно влизане

  • CDT път

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

Човек ще използва имейл адрес или потребителско име, за да влезе в графичния интерфейс на ClusterControl, както е показано на следващата екранна снимка (обърнете внимание на текста за място за полето потребителско име):

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

Разрешения и контрол на достъп

В новото управление на потребителите разрешенията и контролите за достъп се контролират от набор от текстови формуляри за списък за контрол на достъпа (ACL), наречени четене (r), запис (w) и изпълнение (x). Всички обекти и функционалности на ClusterControl са структурирани като част от дърво на директории, ние нарекохме това дърво на директории CMON (CDT) и всеки запис е собственост на потребител, група и ACL. Можете да го мислите като подобен на разрешенията за файлове и директории в Linux. Всъщност реализацията на ClusterControl за контрол на достъп следва стандартните POSIX списъци за контрол на достъпа.

За да поставите пример, разгледайте следните команди. Извлечехме стойността на Cmon Directory Tree (CDT) за нашия клъстер, като използвахме командния ред "s9s tree" (представете си това като ls -al в UNIX). В този пример името на нашия клъстер е „PostgreSQL 12“, както е показано по-долу (обозначено с „c“ в началото на реда):

$ s9s tree --list --long
MODE        SIZE OWNER                      GROUP  NAME
crwxrwx---+    - system                     admins PostgreSQL 12
srwxrwxrwx     - system                     admins localhost
drwxrwxr--  1, 0 system                     admins groups
urwxr--r--     - admin                      admins admin
urwxr--r--     - dba                        admins dba
urwxr--r--     - nobody                     admins nobody
urwxr--r--     - readeruser                 admins readeruser
urwxr--r--     - s9s-error-reporter-vagrant admins s9s-error-reporter-vagrant
urwxr--r--     - system                     admins system
Total: 22 object(s) in 4 folder(s).

Да предположим, че имаме потребител само за четене, наречен readeruser, и този потребител принадлежи към група, наречена readergroup. За да зададем разрешение за четене за читателя потребител и читателска група и нашият CDT път е „/PostgreSQL 12“ (винаги започвайте с „/“, подобно на UNIX), ще изпълним:

$ s9s tree --add-acl --acl="group:readergroup:r--" "/PostgreSQL 12"
Acl is added.
$ s9s tree --add-acl --acl="user:readeruser:r--" "/PostgreSQL 12"
Acl is added.

Сега потребителят на четеца има достъп до ClusterControl чрез GUI и CLI като потребител само за четене за клъстер от база данни, наречен "PostgreSQL 12". Обърнете внимание, че горните примери за манипулиране на ACL са взети от ClusterControl CLI, както е описано в тази статия. Ако се свържете чрез ClusterControl GUI, ще видите следната нова страница за контрол на достъпа:

ClusterControl GUI предоставя по-прост начин за управление на контрола на достъпа. Той предоставя ръководен подход за конфигуриране на разрешенията, собствеността и групирането. Подобно на по-старата версия, всеки клъстер е собственост на екип и можете да посочите различен екип, който да има четене, администратор или да забраните на друг екип да има достъп до клъстера както от ClusterControl GUI, така и от CLI интерфейса.

LDAP

В предишните версии (1.8.1 и по-стари) LDAP удостоверяването се обработваше от интерфейсния компонент чрез набор от таблици (dcps.ldap_settings и dcps.ldap_group_roles). Започвайки от ClusterControl 1.8.2, всички LDAP конфигурации и съпоставяния ще се съхраняват в този конфигурационен файл, /etc/cmon-ldap.cnf.

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

$ systemctl restart cmon # or service cmon restart

Следната екранна снимка показва новия диалогов прозорец за разширени настройки на LDAP:

В сравнение с предишната версия, новото внедряване на LDAP е по-приспособимо, за да поддържа стандартни за индустрията директорийни услуги като Active Directory, OpenLDAP и FreeIPA. Той също така поддържа съпоставяне на атрибути, така че можете да зададете кой атрибут представлява стойност, която може да бъде импортирана в потребителската база данни на ClusterControl като имейл, истинско име и потребителско име.

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

Предимства на новото управление на потребителите

Обърнете внимание, че текущото управление на потребителите все още работи успоредно с новата система за управление на потребителите. Въпреки това силно препоръчваме на нашите потребители да мигрират към новата система преди Q1 2022 г. В момента се поддържа само ръчна миграция. Вижте Миграция към раздела за управление на нови потребители по-долу за подробности.

Новата система за управление на потребителите ще бъде от полза за потребителите на ClusterControl по следните начини:

  • Централизирано управление на потребителите за ClusterControl CLI и ClusterControl GUI. Цялото удостоверяване, упълномощаване и отчитане ще се обработват от услугата ClusterControl Controller (cmon).

  • Разширена и адаптивна LDAP конфигурация. Предишната реализация поддържа само редица атрибути на потребителско име и трябваше да бъде конфигурирана по свой собствен начин, за да работи правилно.

  • Същият потребителски акаунт може да се използва за сигурно удостоверяване на ClusterControl API чрез TLS. Вижте тази статия например.

  • Защитени методи за удостоверяване на потребителя. Новото естествено управление на потребителите поддържа удостоверяване на потребители, като се използват както частни/публични ключове, така и пароли. За LDAP удостоверяване, LDAP обвързванията и търсенията се поддържат чрез SSL и TLS.

  • Последователен изглед на представянето на времето въз основа на настройката на часовата зона на потребителя, особено когато се използва както CLI, така и GUI интерфейс за управление и наблюдение на клъстер на база данни.

  • Защита срещу атаки с груба сила, при която на потребителя може да бъде отказан достъп до системата чрез спиране или забранено влизане.

Миграция към управлението на нови потребители

Тъй като и двете потребителски системи имат различни потребителски акаунти и структура, е много рискова операция да се автоматизира миграцията на потребителя от интерфейс към бекенд. Следователно, потребителят трябва да извърши миграцията на акаунта ръчно след надстройка от 1.8.1 и по-стара версия. Моля, вижте Разрешаване на управление на нови потребители за подробности. За съществуващи потребители на LDAP, моля, вижте раздела Процедура за мигриране на LDAP.

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

  • Системата за управление на потребители на потребителския интерфейс (където потребителят ще влезе с имейл адрес) ще бъде отхвърлена от края на Q1 2022 г. (~1 година след това).

  • Всички предстоящи функции и подобрения ще се базират на новата система за управление на потребителите, обработвана от процеса на cmon backend.

  • Не е интуитивно да имате два или повече манипулатори за удостоверяване, работещи в една система.

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

Последни мисли

ClusterControl с времето се развива в по-усъвършенстван продукт. За да подкрепим растежа, трябва да въведем нови големи промени за по-богато изживяване в дългосрочен план. Очаквайте още функции и подобрения на новата система за управление на потребителите в предстоящите версии!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да наблюдавате MySQL контейнери с Prometheus - внедряване на самостоятелен и рояк::Част първа

  2. Изграждане на горещ режим на готовност на Amazon AWS с помощта на MariaDB Cluster

  3. Как да конфигурирате AppArmor за системи, базирани на MySQL (MySQL/MariaDB репликация + Galera)

  4. Как DATEDIFF() работи в MariaDB

  5. Обявяване на ClusterControl 1.5 – включващ автоматична проверка на архивиране и качване в облак