#hadoop #hdfs #ambari #webhdfs
#hadoop #hdfs #ambari #webhdfs
Вопрос:
Начиная с HDP 3.0, пользовательский интерфейс WebHDFS (т. Е. Проводник файлов пользовательского интерфейса namenode на порту 50070) теперь включает значок корзины, который можно использовать для удаления файлов HDFS. Кажется, это делается путем вызова перехвата удаления rest api, но при этом он также, похоже, обходит любые разрешения на доступ к файлам или папкам. Другими словами, любой, кто может получить доступ к пользовательскому интерфейсу на 50070, теперь может удалить любой файл HDFS.
Есть ли способ сохранить пользовательский интерфейс WebHDFS доступным для пользователей кластера, но запретить им удалять файлы?
Возможные идеи могут каким-то образом отключить или заблокировать перехват УДАЛЕНИЯ, сделать весь WebHDFS доступным только для чтения или реализовать некоторую форму аутентификации, сохраняя при этом доступ к пользовательскому интерфейсу. Что сообщество рекомендует для этого?
Комментарии:
1. В любом случае WebUI по умолчанию небезопасен. Вам нужно включить Kerberos SPNEGO / использовать Knox для полной защиты этой конечной точки
2. Существует несколько причин, по которым кто-то не хочет использовать Kerberos: 1. Кривая обучения (kdc, keytabs не управляются через графический интерфейс) 2. Аутентификация Kerberos влияет на каждого пользователя. 3. WebHDFS, Yarn, Oozie UI полностью заблокированы Kerberos и их нетривиально разрешить снова, так как вам придется начать копаться в том, как браузер аутентифицирует себя. 4. Даже при преодолении всего вышеперечисленного у вас все равно возникнет проблема с тем, как управлять правами на удаление hdfs после входа пользователя в систему. В конце концов, Kerberos выполняет только проверку pass / fail.
3. Конечно, все это допустимо, но без этого ни кластер, ни конечные точки не защищены, а любое другое действие, основанное на имени пользователя, передается как литеральная строка. Например. Вы можете подделать параметр url в webhdfs, чтобы выдавать себя за любого действительного пользователя
Ответ №1:
Я не мог найти никаких предыдущих решений для этого, поэтому я экспериментировал для себя и придумал следующее. Совместное использование в интересах других людей:
Custom core-site:
hadoop.http.staticuser.user = browser
hadoop.user.group.static.mapping.overrides = browser=;
Что это делает, так это меняет пользователя WebHDFS на несуществующего пользователя hdfs ‘browser’ (по умолчанию он, похоже, получает привилегии пользователя супергруппы).
Второе свойство перезаписывает, к каким группам назначается указанный пользователь. В этом случае я перезаписываю пользовательский «браузер», чтобы он не принадлежал ни к какой группе, удаляя таким образом его привилегии супергруппы.
Впоследствии, когда вы проверите пользовательский интерфейс WebHDFS, вы все равно увидите значок корзины рядом с файлами, но если щелкнуть значок, на странице отобразится ошибка разрешений.