K
Если не найдете, напомните через час я посмотрю
Size: a a a
2021 February 04
D
Посмотрите секцию конфигурейшн документации, там прям есть то что вы ищите , в апп мастере
Огонь, спасибо!
spark.redaction.regex
кажется, то, что надо
spark.redaction.regex
кажется, то, что надо
ПФ
предполагается, что имеется доступ к ui-ям, коду / бинарным артефактам (джарники, типа). Хотя в моем случае конкретно речь про питон, но, кажется, это ничего принципиально не меняет.
Тогда шифрование с помощью git-secret, доступ только у доверенных сотрудников с разрешёнными gpg ключами и у билд-сервера
D
Тогда шифрование с помощью git-secret, доступ только у доверенных сотрудников с разрешёнными gpg ключами и у билд-сервера
А я правильно понимаю, что оно в таком сеттинге submit'у передается уже расшифрованное, а значит, будет где-то светить на том же hdfs-е (или как оно делает? всмысле чтобы раздать файлы / джарники ярну)
ПФ
А я правильно понимаю, что оно в таком сеттинге submit'у передается уже расшифрованное, а значит, будет где-то светить на том же hdfs-е (или как оно делает? всмысле чтобы раздать файлы / джарники ярну)
Так броадкаст же. Из памяти всегда можно вытащить всякое чувствительное. Если хранить в чём-то сетевом - то оттуда и экзекьюторы могут читать, собранные ровно в том же сеттинге. Но если есть доступ к hdfs - то да, можно будет стащить ключ и прочитать самому
K
Так броадкаст же. Из памяти всегда можно вытащить всякое чувствительное. Если хранить в чём-то сетевом - то оттуда и экзекьюторы могут читать, собранные ровно в том же сеттинге. Но если есть доступ к hdfs - то да, можно будет стащить ключ и прочитать самому
Ну это уже костыль
K
Вернее колхоз
K
С тем же успехом можно на хдфс положить данные и настроить права доступа к ним
ПФ
Ну это уже костыль
Я не вижу абсолютно секьюрного решения. Спрятать что-то из морды - защита слабее чем не иметь этого нигде в незашифрованном виде
D
я, кажется, криво выразился. Вот, допустим, в джарнике лежит все расшифрованное, к джарнику, допустим ограниченный доступ. Вызываем spark-submit на этот джарник. Чтобы этот джарник раскидался на драйвер (cluster mode) и экзекьюторы, оно ведь кладется перед этим в hdfs? или какой-то дистрибьютед кеш
D
Так броадкаст же. Из памяти всегда можно вытащить всякое чувствительное. Если хранить в чём-то сетевом - то оттуда и экзекьюторы могут читать, собранные ровно в том же сеттинге. Но если есть доступ к hdfs - то да, можно будет стащить ключ и прочитать самому
^ к этому сообщению)
K
я, кажется, криво выразился. Вот, допустим, в джарнике лежит все расшифрованное, к джарнику, допустим ограниченный доступ. Вызываем spark-submit на этот джарник. Чтобы этот джарник раскидался на драйвер (cluster mode) и экзекьюторы, оно ведь кладется перед этим в hdfs? или какой-то дистрибьютед кеш
В хдфс кладется
ПФ
я, кажется, криво выразился. Вот, допустим, в джарнике лежит все расшифрованное, к джарнику, допустим ограниченный доступ. Вызываем spark-submit на этот джарник. Чтобы этот джарник раскидался на драйвер (cluster mode) и экзекьюторы, оно ведь кладется перед этим в hdfs? или какой-то дистрибьютед кеш
Да, конечно кладётся.
D
Ага, кайф, т.е. без acl нормального на hdfs не обойтись
ПФ
А мне кажется что без этого всё равно очень плохо.
ПФ
С полным доступом очень легко всё украсть
K
Ага, кайф, т.е. без acl нормального на hdfs не обойтись
Пока керберезации не будет, кластер голый король
ПФ
Идея с прятанием из морды даёт просто на один слой меньше защиты
D
У нас, блин, бзера через HADOOP_USERNAME можно проставить 🤦 и вперед
K
У нас, блин, бзера через HADOOP_USERNAME можно проставить 🤦 и вперед
Именно