Кассандра на лазури, как настроить группы безопасности

я только что установил кластер данных cassandra. у меня вопрос по группам безопасности и как ограничить доступ. в настоящее время нет групп безопасности для виртуальной сети и для всех виртуальных машин. чтобы каждый мог подключиться к кластеру. проблема начинается, когда я пытаюсь установить группу безопасности в подсети. это связано с тем, что http-связь узлов cassandra (я думаю) используется с общедоступным IP-адресом, а не с внутренним IP-адресом. я получаю сообщение об ошибке в opscenter, что HTTP-соединение не работает.

вопрос в том, как можно ограничить доступ к кластеру (под конкретный ip), но предоставить доступ ко всем узлам cassandra для работы.


azure cassandra datastax opscenter
person Avi Cohen    schedule 05.08.2016    source источник
comment
Большую часть времени вы не хотите предоставлять прямой доступ к cassandra. В производственной среде вы должны разрешать доступ только к прикладному уровню. В разработке вы можете использовать туннель SSH.   -  person grochmal    schedule 05.08.2016
comment
я согласен. проблема в том, как это сделать? возникают конфликты между внутренней связью кассандры и ограничением извне   -  person Avi Cohen    schedule 05.08.2016
comment
какие-либо обновления по этому поводу?   -  person Timmerz    schedule 03.12.2016

Ответы (1)


arrow_upward
0
arrow_downward

Хорошей практикой является обеспечение безопасности при работе в любом общедоступном облаке, будь то Azure, GCE, AWS и т. д. Включение межузлового SSL — очень хорошая идея, поскольку это защитит межузловые сплетни. Затем вы также должны ввести внутреннюю аутентификацию (как минимум), чтобы вам требовался пользователь/пароль для входа в cqlsh. Я бы также порекомендовал использовать SSL от клиента к узлу, в большинстве случаев 1-way должно быть достаточно.

Я не уверен в Azure, но я знаю, что с AWS и GCE экземпляры будут иметь только локальный IP-адрес с внутренней маршрутизацией (обычно в частном диапазоне 10.0.0.0/8), а общедоступный IP-адрес будет через NAT. Обычно вы используете общедоступный IP-адрес в качестве broadcast_address, особенно если вы работаете в разных зонах доступности, где внутренний IP-адрес не маршрутизируется. Вы также можете запустить клиентское приложение, которое может подключаться через общедоступный IP-адрес, поэтому вы также можете установить broadcast_rpc_address как общедоступный. Оба они находятся в файле cassandra.yaml. listen_address и rpc_address — это IP-адреса, к которым будет привязан узел, поэтому они должны быть локально доступны (т. е. вы не можете привязать процесс к IP-адресу, который не настроен на интерфейсе узла).

Сводка

  • Использовать межузловой SSL
  • Использовать клиент для узла SSL
  • Используйте как минимум внутреннюю аутентификацию (также поддерживаются Ldap и Kerberos)

Полезные документы

Я настоятельно рекомендую следовать документации здесь. Внедрение безопасности может быть немного сложным, если вы столкнетесь с препятствиями (вне зависимости от приложения). Я всегда начинаю с того, что убеждаюсь, что кластер работает нормально, без обеспечения безопасности, затем добавляю одну вещь за раз, затем тестирую, проверяю и затем добавляю следующую вещь. Не настраивайте все сразу!

Порты брандмауэра

SSL от клиента к узлу — примечание require_client_auth: true должно быть false для 1-полосного.

SSL между узлами

Подготовка сертификатов SSL

Унифицированная аутентификация (внутренняя, LDAP, Kerberos и т. д.)

Примечание при создании ключей и сертификатов SSL, как правило, вы просто создаете одну пару и используете ее на всех узлах, если у вас есть SSL от узла к узлу. В противном случае, если вы введете новый узел, вам придется импортировать новый сертификат во все узлы, что на самом деле не масштабируется. По моему опыту работы с организациями, использующими большие кластеры, именно так они и управляют. Также клиентские приложения вполне могут использовать тот же ключ или, по крайней мере, другой.

Дополнительная информация/чтение

Двусторонний SSL поддерживается, но не так распространен, как односторонний. Обычно это немного сложнее и включается с помощью require_client_auth: true в cassandra.yaml.

Если вы используете OpsCenter для SSL, в документах (ниже) все описано. Обратите внимание, что по существу это в двух местах:

  • SSL между операторским центром, агентами и кластером (такой же, как SSL от клиента к узлу выше)
  • SSL между OpsCenter и агентами

Конфигурация OpsCenter SSL

Я надеюсь, что это поможет вам достичь того, что вам нужно!

person markc    schedule 28.01.2017