Cassandra Autentificare și autorizare JMX: Creați utilizator

⚡ Rezumat inteligent

Cassandra Securitatea se bazează pe autentificarea internă, permisiunile de rol, regulile firewall și controlul accesului JMX. Această pagină arată cum se activează fiecare strat, se creează utilizatori, se acordă permisiuni și se securizează accesul de la distanță la nodetool.

  • 🔐 Două straturi: Autentificarea dovedește cine este un utilizator; autorizarea decide ce poate face acel utilizator.
  • ⚙️ Activează-l: Ambele sunt dezactivate în mod implicit și se activează prin setările de autentificare și autorizare.
  • 👤 Cont implicit: Superutilizatorul Cassandra încorporat creează fiecare cont, așa că schimbați-i parola imediat.
  • 🔑 Modelul de grant: Permisiuni precum SELECT, MODIFY și ALTER sunt acordate per resursă cu GRANT.
  • 📡 Controlul porturilor: Deschideți porturile 7000, 7001, 7199 și 9042 între noduri și păstrați JMX autentificat.

Cassandra Autentificare și autorizare JMX

Există două tipuri de securitate în Apache Cassandra și DataStax Enterprise.

  • Autentificare internă
  • Autorizare

Ce este autentificarea și autorizarea internă

Autentificarea internă este practic validarea unei conexiuni a utilizatorului. Utilizatorul este autentificat cu nume de utilizator și parolă. Toate conturile de utilizator sunt gestionate în Cassandra intern.

Autorizarea internă se ocupă de permisiunea unui utilizator. Se referă la acțiunile pe care un utilizator le poate efectua. De exemplu, putem acorda permisiuni precum care utilizator are doar permisiunea de citire a datelor, care utilizator are permisiunea de scriere a datelor și care utilizator are permisiunea de ștergere a datelor.

Totuși, autentificarea poate fi controlată și extern cu Kerberos (Kerberos este utilizat pentru a gestiona în siguranță acreditările) și LDAP (LDAP este utilizat pentru a păstra informații autorizate despre conturi, cum ar fi la ce au permisiunea de a accesa).

Autentificarea externă este autentificarea care este acceptată cu Kerberos și LDAP. Apache Cassandra nu acceptă autentificare externă.

Doar DataStax Enterprise acceptă autentificarea externă cu Kerberos și LDAP, în timp ce autentificarea internă este acceptată atât în Apache Cassandra precum și DataStax Enterprise.

Configurați autentificarea și autorizarea

In Cassandra, în mod implicit, opțiunile de autentificare și autorizare sunt dezactivate. Trebuie să configurați fișierul cassandra.yaml pentru a activa autentificarea și autorizarea.

Deschideți fișierul cassandra.yaml și eliminați comentariile de la liniile care se ocupă de autentificarea și autorizarea internă, așa cum se arată mai jos.

liniile de autentificare și autorizare cassandra.yaml necomentate

  • În cassandra.yaml, în mod implicit, valoarea autentificatorului este „AllowAllAuthenticator”. Schimbați această valoare a autentificatorului din „AllowAllAuthenticator” în „com.datastax.bdp.cassandra.auth.PasswordAuthenticator”.
  • În mod similar, în cassandra.yaml, în mod implicit, valoarea autorizatorului va fi „AllowAllAuthorizer”. Schimbați această valoare a autorizatorului din „AllowAllAuthorizer” în „com.datastax.bdp.cassandra.auth”.CassandraAutorizatorul'.

Aceste două nume de clase sunt valorile DataStax Enterprise. Pe open-source Apache Cassandra aceleași setări iau PasswordAuthenticator și CassandraAuthorizer, iar acreditările se află apoi în system_auth spațiu cheie, al cărui factor de replicare ar trebui crescut peste unu.

Logare

Acum autentificarea este activată, dacă încercați să accesați orice spațiu de taste, Cassandra va returna o eroare.

În mod implicit, Cassandra furnizează supercontului numele de utilizator „cassandra” și parola „cassandra”. Prin conectarea la contul „cassandra”, puteți face ce doriți.

Să vedem captura de ecran de mai jos pentru aceasta, unde nu vă va permite să vă autentificați dacă nu utilizați implicit Cassandra „nume de utilizator” și „parolă”.

Autentificare respinsă în cqlsh când nu sunt utilizate credențialele implicite

Acum, în a doua captură de ecran, puteți vedea după utilizarea Cassandra autentificare implicită, vă puteți autentifica.

Autentificare cqlsh reușită folosind acreditările implicite Cassandra

De asemenea, puteți crea un alt utilizator cu acest cont. Se recomandă schimbarea parolei din cea implicită. Iată un exemplu de conectare ca Cassandra utilizator și schimbarea parolei implicite.

alter user cassandra with password 'newpassword';

Creați un utilizator nou

Conturile noi pot fi create cu contul „cassandra”.

Pentru crearea unui utilizator nou, se specifică numele de utilizator și parola, împreună cu faptul dacă utilizatorul este sau nu superutilizator. Doar un superutilizator poate crea utilizatori noi.

create user robin with password 'manager' superuser;
create user robin with password 'newhire';

Puteți obține o listă cu toți utilizatorii după următoarea sintaxă.

list users;

Rezultatul listează fiecare cont împreună cu flag-ul său de superutilizator.

Rezultatul comenzii list users care afișează conturi și flag-uri superutilizator

Utilizatorii pot fi abandonați după următoarea sintaxă.

drop user laura;

Autorizare

Autorizarea este atribuirea de permisiuni utilizatorilor, decizând ce acțiune poate efectua un anumit utilizator.

Iată sintaxa generică pentru alocarea permisiunii utilizatorilor.

GRANT permission ON resource TO user

Există următoarele tipuri de permisiuni care pot fi acordate utilizatorului.

  1. Toate colectiile
  2. MODIFICA
  3. AUTORIZA
  4. CREATE
  5. CĂDERE BRUSCA
  6. MODIFICA
  7. SELECT

Iată exemple de atribuire a permisiunii utilizatorului.

Create user laura with password 'newhire'; 
grant all on dev.emp to laura;
revoke all on dev.emp to laura;
grant select on dev.emp to laura;

Un nou utilizator „laura” este creat cu parola „newhire”.

Iată exemplul în care utilizatorul „laura” încearcă să acceseze tabela emp_bonus. Laura are doar permisiunea de a accesa dev.emp și nicio permisiune asupra tabelei dev.emp_bonus, motiv pentru care a fost returnată o eroare.

Eroare returnată când Laura interoghează tabelul emp_bonus fără permisiune

select* form emp_bonus;

Puteți obține o listă cu toate permisiunile atribuite utilizatorului. Iată un exemplu de obținere a informațiilor despre permisiuni.

Rezultatul listei cu toate permisiunile Laurei

list all permissions of laura;

De asemenea, puteți lista toate permisiunile asupra unei resurse. Iată un exemplu de obținere a permisiunii dintr-un tabel.

Rezultatul listei tuturor permisiunilor pentru fișierul dev.emp

list all permissions on dev.emp;

Configurarea paravanului de protecție

Dacă firewall-ul rulează, următoarele porturi trebuie să fie deschise pentru comunicarea între noduri, inclusiv unele Cassandra porturi. Dacă Cassandra porturile nu vor fi deschise, Cassandra Nodurile vor acționa ca servere de baze de date independente, în loc să se alăture clusterului de baze de date.

Cassandra Porturi client

Numarul portului Descriere
9042 Cassandra Port client
9160 Cassandra Client Port Thrift

Cassandra Porturi internod

Numarul portului Descriere
7000 Cassandra Comunicarea clusterului internod
7001 Cassandra Comunicare cluster SSL internod
7199 Cassandra Port de monitorizare JMX

Porturile publice

Numarul portului Descriere
22 Port SSH
8888 Site-ul OpsCenter. Solicitare http de browser.

Cassandra Porturile OpsCenter

Numarul portului Descriere
61620 Port de monitorizare OpsCenter.
61621 Port agent Opscenter

Driverele actuale utilizează doar portul 9042; portul 9160 deservește interfața Thrift veche și poate rămâne închis pe clustere noi.

Activarea autentificării JMX

Cu setările implicite ale Cassandra, JMX poate fi accesat doar de pe localhost. Dacă doriți să accesați JMX de la distanță, modificați setarea LOCAL_JMX în cassandra-env.sh și activați autentificarea sau SSL.

După ce activați autentificarea JMX, asigurați-vă OpsCenter și nodetool sunt configurate pentru a utiliza autentificarea.

Procedură

Există următorii pași pentru a activa autentificarea JMX.

  1. În fișierul cassandra-env.sh, adăugați sau actualizați următoarele rânduri.
    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

    De asemenea, modificați setarea LOCAL_JMX în cassandra-env.sh.

    LOCAL_JMX=no
  2. Copiați fișierul jmxremote.password.template din /jdk_install_location/lib/management/ în /etc/cassandra/ și redenumiți-l în jmxremote.password.
    cp /jdk_install_dir/lib/management/jmxremote.password.template /etc/cassandra/jmxremote.password
  3. Schimbați dreptul de proprietate asupra jmxremote.password la utilizatorul pe care îl executați Cassandra cu și modificați permisiunea doar pentru citire.
    chown cassandra:cassandra /etc/cassandra/jmxremote.password 
    chmod 400 /etc/cassandra/jmxremote.password
  4. Editați jmxremote.password și adăugați utilizatorul și parola pentru utilitarele compatibile cu JMX:
    monitorRole QED 
    controlRole R&D 
    cassandra cassandrapassword
  5. Adauga Cassandra utilizator cu permisiunea de citire și scriere la /jdk_install_location/lib/management/jmxremote.access
    monitorRole readonly
    cassandra readwrite
    controlRole readwrite \
    create javax.management.monitor.,javax.management.timer. \ 
    unregister
  6. Repornire Cassandra.
  7. Rulați nodetool cu Cassandra utilizator și parolă.
    $ nodetool status -u cassandra -pw cassandra

Întrebări frecvente

Ambele se află în spațiul de chei system_auth, în tabelele roles și role_permissions. Deoarece o replică pierdută a system_auth poate bloca accesul tuturor, creșteți factorul de replicare înainte de a activa autentificarea în producție.

Rolurile CQL au înlocuit sintaxa utilizator mai veche. Un rol deține permisiuni și poate fi acordat altor roluri, așadar CREATE ROLE înlocuiește CREATE USER în versiunile actuale, care păstrează comenzile utilizatorului ca aliasuri.

Nu. Autentificarea dovedește doar identitatea; parolele traversează rețeaua în mod clar, cu excepția cazului în care client_encryption_options este activat. Activați TLS separat pentru traficul client-nod și nod-nod.

Creați un superutilizator dedicat, apoi schimbați parola Cassandra încorporată sau ștergeți contul. Lăsarea activă a perechii Cassandra/Cassandra documentate este cea mai comună metodă. Cassandra configurație greșită.

Permisiunile sunt stocate în cache. O modificare intră în vigoare numai după expirarea ferestrei de valabilitate a permisiunilor, așadar scurtați setarea respectivă în cassandra.yaml sau reporniți nodul atunci când testați o acordare sau o revocare.

JMX neautentificat pe portul 7199 permite controlul complet al nodurilor, inclusiv dezafectarea. Cassandra prin urmare, îl leagă local, iar accesul la distanță ar trebui deschis doar cu un fișier de parole sau SSL instalat.

Modelele de învățare automată profilează formele normale de interogare, orele de conectare și adresele sursă pentru fiecare rol, apoi semnalează abateri, cum ar fi citirea unui spațiu cheie fără legătură cu un cont de aplicație. Aceasta indică faptul că regulile statice de utilizare abuzivă a acreditărilor nu sunt utilizate corespunzător.

Copilot redactează rapid instrucțiunile CREATE ROLE și GRANT dintr-un comentariu, dar tinde să sugereze permisiuni largi. RevVizualizați fiecare grant generat cu cel mai mic privilegiu înainte de a-l rula pe un mediu live grup.

Rezumați această postare cu: