Efter uppgradering till ClusterControl 1.8.2 bör du få följande meddelandebanner:
Vad är det med det? Det är en avskrivningsbesked för det nuvarande användarhanteringssystemet till förmån för det nya användarhanteringssystemet som hanteras av ClusterControl controller-tjänsten (cmon). När du klickar på bannern omdirigeras du till sidan för att skapa användare för att skapa en ny administratörsanvändare, som beskrivs i den här användarhandboken.
I det här blogginlägget kommer vi att titta på det nya användarhanteringssystemet som introducerats i ClusterControl 1.8.2, och för att se hur det skiljer sig från de tidigare. Bara för att förtydliga, det gamla användarhanteringssystemet kommer fortfarande att fungera sida vid sida med det nya användarautentiserings- och hanteringssystemet fram till första kvartalet 2022. Från och med nu kommer alla nya installationer för ClusterControl 1.8.2 och senare att konfigureras med den nya användaren ledningssystem.
Användarhantering före 1.8.2
ClusterControl 1.8.1 och äldre lagrar användarinformation och redovisning i en webbgränssnittsdatabas som kallas "dcps". Denna databas är oberoende av cmon-databasen som används av ClusterControl Controller-tjänsten (cmon).
Användarkonton och autentisering
Ett användarkonto består av följande information:
-
Namn
-
Tidszon
-
E-post (används för autentisering)
-
Lösenord
-
Roll
-
Team
Man skulle använda en e-postadress för att logga in på ClusterControl GUI, som visas i följande skärmdump:
När du är inloggad kommer ClusterControl att leta upp den organisation som användaren tillhör och sedan tilldela den rollbaserade åtkomstkontrollen (RBAC) för åtkomst till ett specifikt kluster och funktioner. Ett team kan ha noll eller flera kluster, medan en användare måste tillhöra ett eller flera team. Att skapa en användare kräver en roll och ett team som skapats i förväg. ClusterControl kommer med ett standardteam som heter Admin och 3 standardroller - Super Admin, Admin och User.
Behörighet och åtkomstkontroll
ClusterControl 1.8.1 och äldre använde en UI-baserad åtkomstkontroll baserad på rolltilldelning. I en annan term kallade vi detta rollbaserad åtkomstkontroll (RBAC). Administratören skulle skapa roller och varje roll skulle tilldelas en uppsättning behörigheter för att komma åt vissa funktioner och sidor. Rolltillämpningen sker på front-end-sidan, där ClusterControl-kontrolltjänsten (cmon) inte har någon aning om huruvida den aktiva användaren har möjlighet att komma åt funktionaliteten eftersom informationen aldrig har delats mellan dessa två autentiseringsmotorer. Detta skulle göra autentisering och auktorisering svårare att kontrollera i framtiden, särskilt när man lägger till fler funktioner som är kompatibla med både GUI och CLI-gränssnitt.
Följande skärmdump visar tillgängliga funktioner som kan styras via RBAC:
Administratören behöver bara välja den relevanta åtkomstnivån för specifika funktioner, och den kommer att lagras i "dcps"-databasen och sedan användas av ClusterControl GUI för att tillåta UI-resurser till GUI-användarna. Åtkomstlistan som skapas här har inget att göra med CLI-användarna.
LDAP
ClusterControl pre-1.8.1 använde PHP LDAP-modulen för LDAP-autentisering. Den stöder Active Directory, OpenLDAP och FreeIPA katalogtjänster men endast ett begränsat antal LDAP-attribut kan användas för användaridentifiering som uid, cn eller sAMAccountName. Implementeringen är ganska enkel och stöder inte avancerad användar-/gruppbasfiltrering, attributmappning och TLS-implementering.
Följande är informationen som behövs för LDAP-inställningar:
Eftersom detta är en gränssnittstjänst lagras LDAP-loggfilen under webbappkatalog, specifikt på /var/www/html/clustercontrol/app/log/cc-ldap.log. En autentiserad användare kommer att mappas till en viss ClusterControl-roll och ett särskilt team, enligt definitionen på LDAP-gruppmappningssidan.
Användarhantering efter 1.8.2
I den här nya versionen stöder ClusterControl både autentiseringshanterare, frontend-autentisering (med e-postadress) och backend-autentisering (med användarnamn). För backend-autentisering lagrar ClusterControl användarinformationen och redovisningen i cmon-databasen som används av ClusterControl Controller-tjänsten (cmon).
Användarkonton och autentisering
Ett användarkonto består av följande information:
-
Användarnamn (används för autentisering)
-
E-postadress
-
Fullständigt namn
-
Taggar
-
Ursprung
-
Inaktiverad
-
Stäng av
-
Grupper
-
Ägare
-
ACL
-
Mislyckade inloggningar
-
CDT-sökväg
Jämfört med den gamla implementeringen har den nya användarhanteringen mer information för en användare, vilket möjliggör komplex manipulering av användarkonton och bättre åtkomstkontroll med förbättrad säkerhet. En användarautentiseringsprocess är nu skyddad mot brute-force-attacker och kan avaktiveras av underhålls- eller säkerhetsskäl.
Man skulle använda en e-postadress eller ett användarnamn för att logga in på ClusterControl GUI, som visas i följande skärmdump (var uppmärksam på platshållartexten för fältet Användarnamn):
Om användaren loggar in med en e-postadress kommer användaren att autentiseras via den utfasade frontend-användarhanteringstjänsten och om ett användarnamn tillhandahålls kommer ClusterControl automatiskt att använda den nya backend-användarhanteringstjänsten som hanteras av kontrolltjänsten. Båda autentiseringarna fungerar med två olika uppsättningar av användarhanteringsgränssnitt.
Behörighet och åtkomstkontroll
I den nya användarhanteringen kontrolleras behörigheter och åtkomstkontroller av en uppsättning textformer för åtkomstkontrolllista (ACL) som kallas läs (r), skriv (w) och kör (x). Alla ClusterControl-objekt och funktioner är strukturerade som en del av ett katalogträd, vi kallade detta CMON Directory Tree (CDT) och varje post ägs av en användare, en grupp och en ACL. Du kan tänka på det som liknar Linux-fil- och katalogbehörigheter. Faktum är att implementeringen av ClusterControl åtkomstkontroll följer standard POSIX Access Control Lists.
För att lägga till ett exempel, överväg följande kommandon. Vi hämtade Cmon Directory Tree-värdet (CDT) för vårt kluster genom att använda kommandoraden "s9s tree" (föreställ dig detta som ls -al i UNIX). I det här exemplet är vårt klusternamn "PostgreSQL 12", som visas nedan (indikeras av "c" i början av raden):
$ 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).
Anta att vi har en skrivskyddad användare som heter readeruser, och den här användaren tillhör en grupp som heter readergroup. För att tilldela läsbehörighet för läsaranvändare och läsargrupp, och vår CDT-sökväg är "/PostgreSQL 12" (börja alltid med en "/", liknande UNIX), kör vi:
$ 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.
Nu kan läsaren komma åt ClusterControl via GUI och CLI som en skrivskyddad användare för ett databaskluster som heter "PostgreSQL 12". Observera att ovanstående ACL-manipulationsexempel togs från ClusterControl CLI, som beskrivs i den här artikeln. Om du ansluter via ClusterControl GUI kommer du att se följande nya åtkomstkontrollsida:
ClusterControl GUI ger ett enklare sätt att hantera åtkomstkontrollen. Det ger en vägledd metod för att konfigurera behörigheter, äganderätt och grupperingar. I likhet med den äldre versionen ägs varje kluster av ett team, och du kan ange att ett annat team ska ha en läsning, admin eller förbjuda ett annat team från att komma åt klustret från både ClusterControl GUI eller CLI-gränssnitt.
LDAP
I de tidigare versionerna (1.8.1 och äldre) hanterades LDAP-autentisering av frontend-komponenten genom en uppsättning tabeller (dcps.ldap_settings och dcps.ldap_group_roles). Från och med ClusterControl 1.8.2 kommer alla LDAP-konfigurationer och mappningar att lagras i denna konfigurationsfil, /etc/cmon-ldap.cnf.
Det rekommenderas att konfigurera LDAP-inställning och gruppmappningar via ClusterControl-gränssnittet eftersom alla ändringar av den här filen kommer att kräva en omladdning till styrenhetsprocessen, som utlöses automatiskt när LDAP konfigureras via användargränssnittet. Du kan också göra direkta ändringar i filen, men du måste ladda om cmon-tjänsten manuellt genom att använda följande kommandon:
$ systemctl restart cmon # or service cmon restart
Följande skärmdump visar den nya dialogrutan för avancerade LDAP-inställningar:
Jämfört med den tidigare versionen är den nya LDAP-implementeringen mer anpassningsbar för att stödja industristandardiserade katalogtjänster som Active Directory, OpenLDAP och FreeIPA. Den stöder också attributmappningar så att du kan ställa in vilket attribut som representerar ett värde som kan importeras till ClusterControl-användardatabasen som e-post, riktiga namn och användarnamn.
För mer information, kolla in användarhandboken för LDAP-inställningar.
Fördelar med den nya användarhanteringen
Observera att den nuvarande användarhanteringen fortfarande fungerar sida vid sida med det nya användarhanteringssystemet. Vi rekommenderar dock starkt våra användare att migrera till det nya systemet före Q1 2022. Endast manuell migrering stöds för tillfället. Se Migrering till avsnittet Ny användarhantering nedan för mer information.
Det nya användarhanteringssystemet kommer att gynna ClusterControl-användare på följande sätt:
-
Centraliserad användarhantering för ClusterControl CLI och ClusterControl GUI. All autentisering, auktorisering och redovisning kommer att hanteras av ClusterControl Controller-tjänsten (cmon).
-
Avancerad och anpassningsbar LDAP-konfiguration. Den tidigare implementeringen stöder bara ett antal användarnamnsattribut och måste konfigureras på sitt eget sätt för att få det att fungera korrekt.
-
Samma användarkonto kan användas för att autentisera till ClusterControl API säkert via TLS. Kolla till exempel den här artikeln.
-
Säkra användarautentiseringsmetoder. Den nya inbyggda användarhanteringen stöder användarautentisering med både privata/offentliga nycklar och lösenord. För LDAP-autentisering stöds LDAP-bindningar och uppslagningar via SSL och TLS.
-
En konsekvent vy av tidsrepresentation baserad på användarens tidszonsinställning, särskilt när man använder både CLI och GUI-gränssnitt för hantering och övervakning av databaskluster.
-
Skydd mot brute force-attacker, där en användare kan nekas åtkomst till systemet via avstängning eller inaktiverade inloggningar.
Migrering till den nya användarhanteringen
Eftersom båda användarsystemen har olika användarkonto och struktur är det en mycket riskabel operation att automatisera användarmigreringen från frontend till backend. Därför måste användaren utföra kontomigreringen manuellt efter uppgradering från 1.8.1 och äldre. Se Aktivera ny användarhantering för mer information. För befintliga LDAP-användare, se avsnittet LDAP-migreringsprocedur.
Vi rekommenderar starkt användare att migrera till det nya systemet av följande skäl:
-
Användarhanteringssystemet för användargränssnittet (där en användare skulle logga in med en e-postadress) kommer att fasas ut av slutet av första kvartalet 2022 (~1 år från nu).
-
Alla kommande funktioner och förbättringar kommer att baseras på det nya användarhanteringssystemet, som hanteras av cmon backend-processen.
-
Det är kontraintuitivt att ha två eller flera autentiseringshanterare som körs på ett enda system.
Om du har problem och behöver hjälp med migreringen och implementeringen av det nya användarhanteringssystemet ClusterControl, tveka inte att kontakta oss via supportportalen, communityforumet eller Slack-kanalen.
Sluta tankar
ClusterControl utvecklas med tiden till en mer sofistikerad produkt. För att stödja tillväxten måste vi införa nya stora förändringar för en rikare erfarenhet på lång sikt. Förvänta dig fler funktioner och förbättringar av det nya användarhanteringssystemet i de kommande versionerna!