Cassandra JMX удостоверяване и оторизация: Създайте потребител
Дейвид Картър
Има два вида сигурност в Apache Cassandra и предприятие Datastax.
- Вътрешно удостоверяване
- Упълномощаване
Какво е вътрешно удостоверяване и оторизация
Вътрешното удостоверяване основно валидира потребителската връзка. Потребителят се удостоверява с потребителско име и парола. Всички потребителски акаунти се управляват в Cassandra вътрешно.
Вътрешното оторизиране се занимава с разрешението на потребителя. Той се занимава с това какви действия може да извърши потребителят. Например, можем да дадем разрешение на потребителя, като например кой потребител има разрешение само за четене на данни, кой потребител има разрешение за запис на данни и кой потребител има разрешение за изтриване на данни.
Удостоверяването обаче може да се управлява и външно с Kerberos (Kerberos се използва за безопасно управление на идентификационните данни) и LDAP (LDAP се използва за съхраняване на достоверна информация за акаунтите, като например това, до което им е разрешен достъп).
Външното удостоверяване е удостоверяването, което се поддържа с Kerberos и LDAP. Apache Cassandra не поддържа външно удостоверяване.
Само datastax enterprise поддържа външно удостоверяване с Kerberos и LDAP. Докато вътрешното удостоверяване се поддържа както в Apache Cassandra както и предприятието Datastax.
Конфигуриране на удостоверяване и оторизация
In Cassandra, по подразбиране опциите за удостоверяване и оторизация са деактивирани. Трябва да конфигурирате Cassandra.yaml файл за разрешаване на удостоверяване и оторизация.
отворено Cassandra.yaml файл и разкоментирайте редове, които се занимават с вътрешно удостоверяване и оторизация.
- In Cassandra.yaml файл, по подразбиране стойността на удостоверителя е „AllowAllAuthenticator“. Променете стойността на този удостоверител от „AllowAllAuthenticator“ на „com.datastax.bdp.cassandra.auth.PasswordAuthenticator“.
- По същия начин в Cassandra.yaml файл, по подразбиране стойността на авторизатора ще бъде „AllowAllAuthorizor“. Променете тази стойност на авторизатора от „AllowAllAuthorizor“ на „com.datastax.bdp.cassandra.auth.CassandraУпълномощител'.
Влизане
Сега удостоверяването е активирано, ако се опитате да получите достъп до което и да е ключово пространство, Cassandra ще върне грешка.
По подразбиране Cassandra предоставя супер акаунт с потребителско име „cassandra“ и парола „cassandra“. Като влезете в „Cassandra' акаунт, можете да правите каквото искате.
Нека видим екранната снимка по-долу за това, където няма да ви позволи да влезете, ако не използвате стандартния Cassandra „потребителско име“ и „парола“.
Сега, във втората екранна снимка, можете да видите след използване Cassandra идентификационни данни за вход по подразбиране, можете да влезете.
Можете също да създадете друг потребител с този акаунт. Препоръчително е да промените паролата от стандартната. Ето примера за влизане Cassandra потребител и промяна на паролата по подразбиране.
alter user cassandra with password 'newpassword';
Създаване на нов потребител
Нови акаунти могат да бъдат създадени с „Cassandra' сметка.
За създаване на нов потребител, влизане, паролата се посочва заедно с това дали потребителят е супер потребител или не. Само супер потребител може да създава нови потребители.
create user robin with password 'manager' superuser; create user robin with password 'newhire';
Можете да получите списък с всички потребители чрез следния синтаксис.
list users;
Потребителите могат да бъдат премахнати чрез следния синтаксис.
drop user laura;
Упълномощаване
Упълномощаването е предоставяне на разрешение на потребителите какво действие може да извърши даден потребител.
Ето общия синтаксис за даване на разрешение на потребителите.
GRANT permission ON resource TO user
Има следните типове разрешения, които могат да бъдат предоставени на потребителя.
- ALL
- ПРОМЕНИ
- РАЗРЕШАВАНЕ
- CREATE
- Капка
- МОДИФИЦИРАЙТЕ
- МАРКИРАЙ
Ето примери за даване на разрешение на потребителя.
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;
Създава се нов потребител 'laura' с парола 'newhire'.
Ето примера, в който потребител 'laura' се опитва да получи достъп до таблицата emp_bonus. Laura има само разрешение за достъп до dev.emp и няма разрешение за тази таблица dev.emp_bonus, затова е върната грешка.
select* form emp_bonus;
Можете да получите списък с всички разрешения, които са присвоени на потребителя. Ето примера за получаване на информация за разрешение.
list all permissions of laura;
Можете също така да изброите всички разрешения на ресурса. Ето примера за получаване на разрешение от таблица.
list all permissions on dev.emp;
Конфигуриране на защитна стена
Ако защитната стена работи, следните портове трябва да бъдат отворени за комуникация между възли, включително някои Cassandra пристанища. Ако Cassandra портовете няма да бъдат отворени, Cassandra възлите ще действат като самостоятелен сървър на база данни, вместо да се присъединят към клъстера на базата данни.
Cassandra Клиентски портове
| Номер на пристанище | Descriptйон |
|---|---|
| 9042 | Cassandra Клиентски порт |
| 9160 | Cassandra Client Port Thrift |
Cassandra Междувъзлови портове
| Номер на пристанище | Descriptйон |
|---|---|
| 7000 | Cassandra междувъзлова клъстерна комуникация |
| 7001 | Cassandra SSL междувъзлова клъстерна комуникация |
| 7199 | Cassandra JMX порт за наблюдение |
Обществени пристанища
| Номер на пристанище | Descriptйон |
|---|---|
| 22 | SSH порт |
| 8888 | Уебсайт на OpsCenter. http заявка на браузъра. |
Cassandra OpsCenter портове
| Номер на пристанище | Descriptйон |
|---|---|
| 61620 | Порт за наблюдение на OpsCenter. |
| 61621 | Порт на агент на Opscenter |
Активиране на JMX удостоверяване
С настройките по подразбиране на Cassandra, JMX може да бъде достъпен само от локалния хост. Ако искате отдалечен достъп до JMX, променете настройката LOCAL_JMX Cassandra-env.sh и активирайте удостоверяване или SSL.
След като активирате JMX удостоверяване, уверете се OpsCenter и nodetool са конфигурирани да използват удостоверяване.
Процедура
Има следните стъпки за активиране на JMX удостоверяване.
- Във файла cassandra-env.sh добавете или актуализирайте следните редове.
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true" JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"
Също така променете настройката LOCAL_JMX Cassandra-енв.ш
LOCAL_JMX=no
- Копирайте jmxremote.password.template от /jdk_install_location/lib/management/ в /etc/cassandra/ и го преименувайте tojmxremote.password.
cp />jdk_install_dir/lib/management/jmxremote.password.template /etc/cassandra/jmxremote.password
- Променете собствеността на jmxremote.password на потребителя, който управлявате Cassandra с и промяна на разрешението само за четене
chown cassandra:cassandra /etc/cassandra/jmxremote.password chmod 400 /etc/cassandra/jmxremote.password
- Редактирайте jmxremote.password и добавете потребителя и паролата за JMX-съвместими помощни програми:
monitorRole QED controlRole R&D cassandra cassandrapassword
- Добавете Cassandra потребител с разрешение за четене и запис на /jdk_install_location/lib/management/jmxremote.access
monitorRole readonly cassandra readwrite controlRole readwrite \ create javax.management.monitor.,javax.management.timer. \ unregister
- Restart Cassandra
- Стартирайте nodetool с Cassandra потребител и парола.
$ nodetool status -u cassandra -pw cassandra
Oбобщение
Този урок обяснява сигурността в Cassandra и конфигуриране Cassandra.yaml файл за активиране на сигурността. Освен това той също така обяснява как може да се създаде нов потребителски акаунт, присвояване на разрешение, конфигуриране на защитната стена и т.н.
