Комментарии 7
Какая-то BDSM`ная аббревиатура
Нужно больше функций налеплять на одну роль. Эффективный менеджмент должен быть эффективным.
Как вы считаете, должен ли мониторинг уязвимостей быть частью Observability? И поддается ли он автоматизации с k8s?
Вот опубликованы новые CVE для компонента, активно использующегося в некоторых частях нашей системы. С одной стороны, система вроде бы не изменилась (как была дырявой, так и осталась). С другой стороны, реагировать-то надо.
Как вы считаете, должен ли мониторинг уязвимостей быть частью Observability?
На мой взгляд да. Список CVE это просто один из типов сигналов для observability системы.
И поддается ли он автоматизации с k8s?
Посмотрите тот же упоминаемы мной Starboard operator, он при изменении ReplicaSet запускает скан прописанных там images и результат оформляет в Custom Resources под названием VulnerabilityReport. И появление данного отчета у вас в системе и есть сигнал, который вы далее уже можете обрабатывать, как хотите.
Вот опубликованы новые CVE для компонента, активно использующегося в некоторых частях нашей системы. С одной стороны, система вроде бы не изменилась (как была дырявой, так и осталась). С другой стороны, реагировать-то надо.
Хорошо собирать SBOM (тоже может быть как сигнал) для images и периодически его перепроверять, так как вы верно отметили, что со временем появляется все больше уязвимостей. Или по старинке периодически пере сканируйте свой image registry, чтобы понять какие на данный момент там есть известные уязвимости.
где говорится, что observability можно построить без логов, метрики и трейсов — трех основных столпов k8s
В смысле? Я сомневаюсь, что это возможно, но вот расширить на дополнительные типы ресурсов - почему нет. Вот тот же SBOM и список образов в системе - с одной стороны это можно подавать и как метрики (но с этими данными будет неудобно работать), так и как и какие-то отдельные сущности. Возможно, что типизированные. И тут могут помочь CR кубернетеса.
Потому что если на стадии освоения новой программы у вас будут сложности с сертификатами или с какими-то ее политиками, то, скорее всего, у вас улетучится желание осваивать новую технологию.
Касательно этого - я часто вижу, что многие системы небезопасны по дефолту. Тот же rhel, Ubuntu и прочие. У меня есть теория, почему так происходит. Во-первых, это создаёт целый огромный рынок по доконфигурированию целевых систем в безопасный режим. Хотя по идее вендор мог это сделать изначально. Очевидно, что вся эта работа по созданию безопасный профилей стоит приличных денег, а потом ещё поддерживать это все в актуальном состоянии. Вторая проблема в том, что любая безопасность идёт вразрез с совместимостью. Вот, скажем, мы выпускаем новую версию ос и черт нас дернул сделать /temp/ noexec. А чо - секурно. Но при этом у нас 100500 утилит поломается, которые неявно рассчитывали, что можно выполнять скрипты из временного каталога. Пользователь явно будет не очень доволен. А эти скрипты переписать тоже та ещё пачка денег. С другой стороны, пример того же андроида показывает, что пока ты безопасность нк будешь выкручивать на максималки - ни один разработчик под твою платформу не будет ее имплементировать. Вспомните - сколько мы говна поели, когда мигрировали приложения с 95 винды на 2000. Или когда мигрировали их для поддержки Юникода. Или y2k. Вот были бы эти требования сразу - жизнь была бы сильно проще. Но и приходим к третьей вещи - что стоимость разработки выросла бы. Действительно, проще забить на все эти требования и сделать фигак фигак и в продакшн и не думать о последствиях. Бизнес результат получил, а риски будут проблемой "будущего я" или того, что будет после разработчика (а он радостно махнёт своим павлиньим хвостом и уйдёт в следующую айти компанию, учитывая тотальный голод на рынке кадров). В общем, работы нам хватит ещё на долгие годы вперёд :)
Kubernetes: трансформация к SecDevSecOpsSec