По заявкам. Разные движки воспринимают ролевую модель айсберг-лейкхауса по-разному. И с этим надо смириться и воспринимать как вариант нормы. Поэтому учимся защищать данные даже в тех ситуациях, когда конкретный движок решит забить на правила. Один из способов- начать работать с S3 ключами. А как? А вот так. 1️⃣ команде пользователю данных выдаем ключ не на весь бакет, а более гранулярно. Пользуемся тем, что если default location у нас s3://ice-bucket/data, то объекты по умолчанию будут разложены по префиксам s3://ice-bucket/data/schema/table. Вот и выписываем их гранулярно на схемы и таблицы. Эти же ключи раскладываем по ноутбукам, спаркам, трино каталогам, аэрфлоу и тд. 2️⃣ В айсберг таблице есть параметр location. Это корень обхода дерева метадаты айсберг и то куда айсберг складывает свой стафф. По умолчанию он берется из настроек коннектора и каталога. Так вот, ничего не мешает этот локейшен точечно переопределить. Например на s3://ice-bucket/secret/ или s3://secret-bucket или (внезапно!) hdfs://path И все будет работать до тех пор пока чтец обладает правами на предоставленных ему s3 ключах. Причем во многих s3 реализациях нельзя на один ключ грантовать права в разных бакетах. Разнося таблицы по бакетам мы получаем гарантию, что команды из чистой зоны физически не смогут добраться до секретной зоны со своими ключами. Вот так мы добавляем доп слой гарантированной безопасности, который будет работать на низком уровне даже если сервисы джейлбрейкнут Ranger или REST Catalog. (А они ведь могут!) Не забудьте только навайбкодить сервис, который будет выпускать, отзывать, аудировать и раскладывать в конфиги и волты ваши s3 ключи! 😎