Comments 10
Где-то в районе бинарника на 2Гб, я понял, что что-то не то. Бинарь? 2Гб?
1) у вас в конфиге nginx есть отсылка к nginx plus. Это действительно так, или какой-то свой или opensource модуль?
2) какова конфигурация vault? Один для всех или на каждый дц свой? Если на каждый дц свой, то как поддержываете консистентность секретов меджу дц? Как построеный HA, и что может произойти, если волт перестанет быть доступен?
EncryptionConfiguration это же шифрование только на уровне etcd
внутри кубов как были get secrets в нешифрованные так и останутся? разве нет?
Попробуйте bitnami SealedSecrets для безопасной доставки секретов
Я бы посоветовал вообще больше времени уделять Research и меньше странным пабликам на хабре. Всё описанное в статье решаеться гораздо более простыми великами. Для компании которая имеет такой штат разработчиков не написать своё кастомное решение для доставки образов стыд и срам, работать с шифрованными секретами можно, для этого надо чуть чуть расширить кубик своими плагинами и всё. Опять же если компания позиционрует себя как опытного потребителя кубика то не иметь таких кастомных расширений она просто не может.
И да, я понимаю что поддержка любой кастомщины сложное дело, но мы ведь говорим не о команде из 2-х разрпботчиков, а о целом огромном подразделении которое отвечает за эксплуатацию всего этого хозяйства. Мы у себя закастомили очень многое, и мы не ВК, мы как раз скорее амбициозный стартап, и нам это оказалось по силам))))
И да, я понимаю что поддержка любой кастомщины сложное дело, но мы ведь говорим не о команде из 2-х разрпботчиков, а о целом огромном подразделении которое отвечает за эксплуатацию всего этого хозяйства.
Далеко не всегда. Всегда надо оценивать трейдоффы от поддержки своего велосипеда и внедрения чужого.
Мы у себя закастомили очень многое, и мы не ВК, мы как раз скорее амбициозный стартап, и нам это оказалось по силам))))
Молодцы. И сколько у вас при этом людей, которые могут фуллтайм инфрой заниматься? Я замечаю, что во многих компаниях - продуктовая разработка в почете и она может творить любую дичь, никакой унификации нет, а выделенной команды девопсов нет (да и не работает она).
Тема доклада актуальная, и не только в масштабах VK. Сам сталкивался с желанием иметь p2p-сидирование образов когда надо было на небольшой кластер (10-16 воркеров) тянуть время от времени многогигабайтные образы (кажется, гугловский tensorflow). Нашел те же варианты что и докладчик, но для тех масштабов это всё оверкилл, хотелось чего-то более легковесного чем кракен, но увы. Выкрутились кэширующим registry:2 в кластере.
Может, с тех пор появилось лёгкое p2p-кэширование для самых маленьких, знает кто?
Как-то в одном из внутренних чатов прозвучала фраза, что ImagePullPolicy IfNotPresent не является безопасной. Условный злоумышленник может подменить локальный image на машине, что будет проигнорировано движком. Ну, мне кажется, у нас будут более серьезные проблемы, чем подмененный image, если злоумышленник уже на нашей машине. Подмена образа — это уязвимость цепочки поставок и тема для отдельного разговора.
там основная проблема в другом. Предположим, что у нас есть мультитенантный кластер. В случае ImagePullPolicy=Always - всегда идет проверка того, что конкретный под из конкретного неймспейса обладает соответствующим regcred, а когда ImagePullPolicy=IfNotPresent - эта проверка байпассится. К сожалению, я не смогу подтвердить это опасение исходным кодом (честно, не смотрел), но могу подтвердить ссылкой на CIS или на сайт Fairwinds: https://www.fairwinds.com/blog/kubernetes-how-to-ensure-imagepullpolicy-set-to-always Как будто в случае указания полного имени образа с sha-суммой это не беда, но давайте будем честны - кто так делает ? :-)
то скачивание и/или подмена образов — не самое худшее, что он может сделать.
не согласен - это может быть шагом к более серьезным проблемам.
Еще очень интересно (не совсем понял) - как решается проблема двойного расходования места на образа. Т.е. если мы делаем локальный кэш слоев на базе docker registry или nginx, то контейнерный движок оттуда все равно будет перекладывать слои к себе во внутренние каталоги /var/lib. Хотелось оптимизировать метрику потребления дискового пространства, т.к. у нас есть некоторые образа и по 10ГиБ, а места на /var/lib попросту не напасешься. Что по этому поводу думает уважаемый автор?
Container image: доставить это немедленно