Похоже, что об этом серьезно не хватает информации, несмотря на то, что установленный elasticsearch чрезвычайно уязвим.
Мое главное опасение при его использовании заключается в том, что я, как неспециалист, не знаю, каковы возможные уязвимости и как их закрыть.
Может ли кто-нибудь объяснить мне метод блокировки elasticsearch, чтобы я мог делать следующее в безопасной среде:
Несколько индексов для каждого пользователя. Предположим, я могу создать это для них заранее, пользователь не должен иметь возможность выполнять операции с индексами других пользователей, за исключением, возможно, запроса их, если ему предоставлено разрешение. (Возможно, какая-то форма секретного ключа в URL-адресе для каждого пользователя?)
Пользователи могут добавлять и удалять объекты из своих индексов по своему желанию, но не удаляют свой индекс.
Некоторая форма ограничения размера памяти для пользователя, чтобы, если что-то пойдет не так, они не могли перегрузить службу.
Я предполагаю, что что-то из этого должно быть сделано на уровне приложения, и я не могу ожидать, что вы напишете это для меня, однако конфигурация по умолчанию слишком открыта, и даже если я предоставлю пользовательский уровень API для этого, кто-то может легко обойти его и связаться напрямую с сервером.
На мой взгляд, единственный способ защитить ES так, как вы просите, - это заблокировать его за другим уровнем приложения и заставить этот уровень обрабатывать https / ssl транспорт, аутентификацию и контроль авторизации.
Что касается ES, был разработан плагин безопасности ES для причалов, не знаю, был ли он успешным, когда я впервые развертывал ES, когда плагин собирался выпустить, поэтому посмотрите на него:
Я предполагаю, что вам нужно будет создать промежуточный HTTP-прокси со всей этой «бизнес-логикой» и разрешить доступ ElasticSearch только с локального хоста. Таким образом, прямой доступ к ES блокируется, и вы можете определять и применять любые политики, которые вам нужны (ура!;)
«даже если я предоставлю пользовательский уровень API для этого, кто-то может легко его обойти»: они не могут, если ES принимает соединения только с локального хоста.
Я не думаю, что ограничения на использование памяти возможны, может быть, вы могли бы предварительно одобрить запросы на уровне прокси?
Я сделал нечто подобное, используя Nginx, работающий перед ES. В Nginx можно настроить «авторизацию» на основе ключевых слов в URL. Обратитесь к варианту использования, определенному в этом документе: http://www.elasticsearch.org/blog/playing-http-tricks-nginx/
Я привязал elasticsearch к туннелю openvpn:
В /etc/elasticsearch/elasticsearch.yml:
network.host: 172.16.xxx.xxx
Где 172.16.xxx.xxx - IP-адреса, назначенные openvpn.