cassandra on azure, как настроить группы безопасности

Question

Я только что установил кластер данных кассандры. У меня вопрос о группах безопасности и о том, как ограничить доступ. В настоящее время нет никаких групп безопасности для vnet и для всех vms. поэтому каждый может подключиться к кластеру. Проблема начинается, когда я пытаюсь установить группу безопасности в подсети. это потому, что http-связь узлов кассандры (я думаю) используется с публичным ip, а не с внутренним ip. я получаю ошибку в opscenter, что http-соединение не работает.

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

Answer 1

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

Я не уверен в 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 также поддерживаются)

Полезное docs

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

Firewall ports

Client to node SSL - примечание require_client_auth: true должно быть false 1-полосная.

Node to node SSL

Preparing SSL certificates

Unified authentication (внутренний, LDAP, Kerberos и т.д.)

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

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

2-путь SSL поддерживается, но его не так часто, как 1-полосная. Это, как правило, немного сложнее и включается с require_client_auth: true в cassandra.yaml

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

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

OpsCenter SSL configuration

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