Обратный прокси Nginx для elasticsearch - вставка фильтров
У меня есть экземпляр elasticsearch, перед которым установлен обратный прокси Nginx, реализующий механизм управления доступом на уровне URL - примерно как описано в этой статье
Это дает мне возможность -индекс детализации, что удобно.
Что я? Я пытаюсь выяснить следующее: могу ли я применить критерии общего фильтра, исключающие результаты поиска и прямого извлечения документов?
Я думаю о «групповой» модели, где документы в моих индексах помечаются по группам, и пользователи могут видеть только результаты и документы для своей группы.
Теперь я знаю, что могу сделать индекс для каждой группы и применить элементы управления на уровне URL. Это может быть моим обходным решением, если я не смогу этого сделать.
Я изучал псевдонимы - похоже, он выполняет 90% того, что я хочу, в том смысле, что я могу ограничить поиск псевдонимом. Но в таком случае я не могу запретить прямой запрос GET с (неавторизованным) идентификатором документа.
Есть ли способ сделать это, или я просто на пути в никуда?
Примечание. Отчасти это объясняется тем, что я пытаюсь использовать стандартную настройку кибаны, и у меня есть перекрывающиеся группы пользователей.
Сегодня, когда я начал новый проект, работая с Elasticsearch, я провел небольшое исследование и обнаружил Search Guard - бесплатную защиту Elasticsearch . Очевидно, я не могу судить (пока), насколько хорошо это работает, но хотел оставить здесь указатель на случай, если вы или другие все еще ищете (а) решение (я), и в случае, если Shield не может быть использован по каким-либо причинам .
Цитируя веб-сайт, это следующие функции:
- Гибкое управление доступом на уровне REST (на основе пользователей / ролей; на основе псевдонимов, индексов и типов)
- Гибкое управление доступом на транспортном уровне (на основе пользователей / ролей; на основе псевдонимов). , индексы и типы)
- Безопасность на уровне документов (DLS): извлекать только документы, соответствующие критериям
- Безопасность на уровне полей (FLS): отфильтровывать поля / исходные части из поискового ответа
- HTTP-аутентификация (базовая, заголовок прокси, SPNEGO / Kerberos, Mutual SSL / CLIENT-CERT)
- Поддержка HTTP-сеанса с помощью файлов cookie
- Гибкие серверы аутентификации (LDAP (s) / Active Directory, на основе файлов, заголовок прокси, собственная Windows через WAFFLE)
- Гибкая авторизация бэкэнды (LDAP (s) / Active Directory, на основе файлов, собственная версия Windows через WAFFLE)
- Межузловое шифрование через SSL / TLS ( Транспортный уровень)
- Уровень безопасности REST через HTTPS (SSL / TLS)
- Поддержка X-Forwarded-For (XFF)
- Ведение журнала аудита
- Анонимный вход / доступ без аутентификации
- Работает с Kibana 4 и logstash
Но есть и ограничения:
- При использовании DLS или FLS вы все равно можете выполнять поиск во всех документах / полях, но не все документы / поля возвращаются
- Контроль доступа на транспортном уровне только с простым логином / паролем
- Нет автоматических мультииндексных фильтров (см. Ниже).
- В настоящее время мониторинг кластера не требует аутентификации и разрешен всегда (это может измениться в будущем)
Может быть, это полезно и полезно для вас или кого-то еще , кто наткнулся на этот пост.
Пока я не могу напрямую ответить на ваш вопрос (+1), Я хотел отметить, что люди, работающие с elastic, наконец, прислушались ко всем запросам людей, требующих контроля доступа для Elasticsearch , и представили Shield . Цитата с веб-сайта:
Благодаря быстрому внедрению Elasticsearch, хранить, искать и анализировать ваши данные стало проще, чем когда-либо. Shield позволяет легко защитить эти данные с помощью имени пользователя и пароля, упрощая при этом вашу архитектуру. Расширенные функции безопасности, такие как шифрование, ролевой контроль доступа, IP-фильтрация и аудит, также доступны, когда они вам нужны.
Ваши данные становятся все более ценным активом. Защитите его паролем с помощью Shield.
Возможно, стоит взглянуть хотя бы на то, соответствует ли это вашим требованиям.