DevSecOps: От сетей и Linux до безопасности Kubernetes

Фундаментальные основы Linux и сетевых протоколов: архитектура, безопасность и управление трафиком

Добро пожаловать в курс DevSecOps: От сетей и Linux до безопасности Kubernetes. Это первая и, пожалуй, самая важная статья цикла. Прежде чем мы начнем разворачивать кластеры Kubernetes, настраивать CI/CD пайплайны и внедрять сканеры уязвимостей вроде Trivy, нам необходимо построить прочный фундамент.

Любая современная облачная инфраструктура, будь то Docker-контейнер или сложный кластер K8s, опирается на базовые примитивы операционной системы Linux и сетевые протоколы. Непонимание того, как работает ядро Linux или как происходит TCP-рукопожатие, делает специалиста слепым при отладке сложных инцидентов безопасности.

Архитектура Linux: Ядро и Пространство пользователя

Операционная система Linux разделена на два основных уровня: Kernel Space (пространство ядра) и User Space (пространство пользователя). Понимание этой границы критически важно для безопасности контейнеров.

!Схема взаимодействия пространства пользователя и ядра через системные вызовы

Изоляция: Namespaces и Cgroups

Контейнеризация — это не магия, а использование двух функций ядра Linux:

Namespaces (Пространства имен): Отвечают за то, что* процесс может видеть. Они изолируют глобальные системные ресурсы. * PID: Изоляция процессов (контейнер видит только свои процессы). * NET: Изоляция сетевого стека (свои IP, порты, таблицы маршрутизации). * MNT: Изоляция файловой системы. Cgroups (Control Groups): Отвечают за то, сколько* ресурсов процесс может использовать. Они ограничивают CPU, память и I/O.

> Контейнеры в Linux — это обычные процессы, которые были ограничены с помощью Namespaces и Cgroups, чтобы создать иллюзию отдельной системы.

Безопасность в Linux: От прав доступа до Capabilities

В классической модели безопасности Linux есть права rwx (чтение, запись, исполнение) и пользователи (владелец, группа, остальные). Однако для DevSecOps этого недостаточно.

Linux Capabilities

Традиционно в Linux есть два типа процессов: привилегированные (root, UID 0) и непривилегированные. Это создает проблему безопасности: если приложению нужно всего лишь открыть порт ниже 1024 (например, веб-сервер на 80 порту), ему приходится давать полные root-права. Если злоумышленник взломает такой сервис, он получит контроль над всей системой.

Capabilities (возможности) разбивают суперсилу root-пользователя на мелкие части. Вместо того чтобы давать полный root, мы можем выдать процессу только конкретную способность.

Примеры Capabilities: * CAP_NET_BIND_SERVICE: Разрешает биндить порты ниже 1024. * CAP_CHOWN: Разрешает менять владельца файлов. * CAP_SYS_ADMIN: Очень мощная привилегия, фактически аналог root (часто требуется для Docker внутри Docker).

Пример проверки capabilities у процесса ping (которому нужен доступ к сырым сокетам):

Docker Security: DinD vs DooD

При построении CI/CD пайплайнов часто возникает необходимость собирать Docker-образы внутри контейнеров (например, в Jenkins или GitLab CI). Здесь мы сталкиваемся с двумя подходами, имеющими разные риски безопасности:

Сетевые протоколы и передача данных

Понимание сети начинается с модели OSI, но на практике инженеры DevSecOps чаще оперируют моделями TCP/IP.

TCP/IP и надежность

Протокол TCP (Transmission Control Protocol) обеспечивает гарантированную доставку данных. Это происходит благодаря механизму "рукопожатия" (Handshake).

Для оценки производительности сети часто используется понятие пропускной способности TCP. Теоретический максимум пропускной способности можно выразить формулой:

где — пропускная способность (бит/с), (Receive Window) — размер окна приема TCP (объем данных, который можно отправить без подтверждения), а (Round Trip Time) — время прохождения сигнала туда и обратно. Если высокий (большая задержка), скорость передачи падает, даже если канал широкий.

DNS: Адресная книга интернета

DNS (Domain Name System) преобразует доменные имена в IP-адреса. В Kubernetes DNS играет ключевую роль (CoreDNS), позволяя сервисам находить друг друга по именам, а не по динамическим IP.

Мониторинг и анализ трафика

Для обеспечения безопасности сети (Network Security) необходимо уметь анализировать, что происходит в каналах связи.

Основные инструменты

Безопасность сети

Основой сетевой безопасности в Linux является Netfilter — фреймворк внутри ядра, который управляет пакетами. Утилиты iptables или более современный nftables являются интерфейсами к Netfilter.

В контексте Kubernetes, сетевые политики (Network Policies) часто реализуются именно через правила iptables или технологию eBPF, ограничивая трафик между подами.

Подготовка к Kubernetes

В следующих статьях мы перейдем к практике:

Но помните: Trivy и kube-bench лишь подсвечивают проблемы. Исправление этих проблем потребует от вас знаний, полученных в этой статье — понимания прав доступа, capabilities и сетевых правил.

Контейнеризация Deep Dive: Dockerfile, Capabilities, безопасность и режимы DinD/DooD

В предыдущей статье мы разобрали фундамент: как ядро Linux использует Namespaces и Cgroups для создания иллюзии изоляции. Теперь пришло время перейти от теории операционных систем к практике DevSecOps. Мы погрузимся в анатомию Docker-образов, разберем, почему root внутри контейнера — это плохая идея, и детально рассмотрим архитектурные паттерны CI/CD, такие как Docker-in-Docker (DinD) и Docker-out-of-Docker (DooD).

Понимание этих концепций критически важно перед тем, как мы начнем масштабировать наши приложения в Kubernetes, так как безопасность кластера начинается с безопасности отдельного контейнера.

Анатомия безопасного Dockerfile

Безопасность начинается не на этапе развертывания, а на этапе написания кода и сборки образа. Dockerfile — это манифест, определяющий состав и поведение вашего контейнера. Ошибки здесь могут свести на нет все усилия по защите периметра.

Минимизация поверхности атаки: Base Images

Выбор базового образа определяет количество уязвимостей (CVE), которые вы наследуете по умолчанию. Образ node:latest может весить почти 1 ГБ и содержать сотни системных библиотек, которые вашему приложению не нужны, но могут быть использованы злоумышленником.

Multi-stage builds

Многоэтапные сборки позволяют отделить инструменты сборки (компиляторы, исходный код, секреты сборки) от финального артефакта.

!Визуализация того, как multi-stage build отбрасывает лишние слои и инструменты, оставляя в финальном образе только бинарный файл.

Пример безопасного подхода:

Проблема пользователя Root

По умолчанию процессы в контейнере запускаются от имени root (UID 0). Если злоумышленник совершит побег из контейнера (Container Breakout), он окажется на хосте с правами суперпользователя.

Всегда создавайте непривилегированного пользователя:

Управление привилегиями: Capabilities Deep Dive

Как мы упоминали ранее, Linux Capabilities разбивают монолитные права root на части. Docker по умолчанию запускает контейнеры с ограниченным набором capabilities. Он отключает опасные возможности, но оставляет базовые, необходимые для работы сети и файловой системы.

Опасные Capabilities

Некоторые возможности фактически эквивалентны полному доступу к хосту:

* CAP_SYS_ADMIN: Самая перегруженная возможность. Позволяет монтировать файловые системы, управлять пространством подкачки, изменять namespaces. Включение этой опции часто требуется для запуска systemd или Docker внутри контейнера, но это огромная дыра в безопасности. * CAP_NET_ADMIN: Позволяет изменять сетевые интерфейсы, таблицы маршрутизации и правила iptables. * CAP_SYS_PTRACE: Позволяет отлаживать процессы, что дает возможность читать память других процессов и внедрять код.

Принцип наименьших привилегий

В DevSecOps мы используем подход "запрещено все, что не разрешено". Лучшая практика — сбросить все привилегии и добавить только необходимые.

Команда запуска может выглядеть так:

Это гарантирует, что даже если приложение будет взломано, злоумышленник не сможет изменить владельца файлов (CAP_CHOWN) или убить процессы (CAP_KILL), если мы явно это не разрешили.

Оценка риска

В информационной безопасности риск часто оценивается по формуле:

где — риск (Risk), — вероятность (Probability) возникновения угрозы, а — влияние (Impact) или ущерб от реализации угрозы. Использование --privileged или CAP_SYS_ADMIN увеличивает до максимума (полная компрометация узла), делая общий риск неприемлемо высоким, даже если вероятность атаки кажется низкой.

CI/CD и проблема сборки: DinD vs DooD

Когда мы строим CI/CD пайплайны (например, в Jenkins, GitLab CI или GitHub Actions), нам часто нужно собрать Docker-образ внутри задачи, которая сама выполняется в Docker-контейнере. Здесь возникает классическая дилемма.

!Сравнение архитектуры Docker-in-Docker (вложенность) и Docker-out-of-Docker (проброс сокета).

1. DinD (Docker in Docker)

В этом режиме внутри контейнера запускается новый, независимый демон Docker.

* Как это работает: Вложенный Docker создает свои собственные образы и контейнеры, ничего не зная о хосте. * Проблема безопасности: Для работы Docker требуются привилегии уровня ядра. Чтобы запустить DinD, внешний контейнер обязан быть запущен с флагом --privileged. Это отключает защиту cgroups, AppArmor/SELinux и маскировку /proc. * Вердикт: Крайне небезопасно. Изоляция практически отсутствует.

2. DooD (Docker out of Docker)

В этом режиме мы не запускаем Docker внутри. Вместо этого мы пробрасываем сокет демона с хоста внутрь контейнера.

* Как это работает: Клиент docker внутри контейнера отправляет команды демону, работающему на хосте. Когда вы пишете docker build, сборку выполняет хост. * Проблема безопасности: Если злоумышленник получает доступ к контейнеру с проброшенным сокетом, он может выполнить команду: Это запустит новый контейнер, который примонтирует корневую файловую систему хоста в папку /host. Злоумышленник получает полный root-доступ к файловой системе сервера. * Вердикт: Опасно, но часто используется из-за удобства кэширования слоев.

Безопасная альтернатива: Rootless Builders

Современный подход в DevSecOps — использование инструментов, которые умеют собирать образы без демона Docker и без привилегий root. Основные игроки:

* Kaniko (от Google): Предназначен для запуска в Kubernetes. Собирает образ слой за слоем в userspace, не требуя привилегированного доступа. * Buildah / Podman: Позволяют управлять контейнерами и образами без единого демона, используя стандартные механизмы fork/exec.

Runtime Security: Seccomp и AppArmor

Даже если Dockerfile идеален, нам нужна защита во время выполнения.

Seccomp (Secure Computing Mode)

Ядро Linux имеет сотни системных вызовов. Веб-серверу обычно нужно лишь небольшое подмножество (read, write, socket, accept). Seccomp позволяет фильтровать доступные syscalls.

Docker применяет профиль seccomp по умолчанию, блокируя около 44 из 300+ вызовов. Однако для критических приложений рекомендуется создавать "белые списки" (allow-lists) только необходимых вызовов.

AppArmor и SELinux

Это системы мандатного управления доступом (MAC). Они работают поверх стандартных прав Linux.

* AppArmor: Работает на основе путей к файлам. Можно создать профиль, который запрещает процессу Nginx писать в /etc, даже если он запущен от root. * SELinux: Работает на основе меток (labels) на файлах и процессах. Более сложен в настройке, но предоставляет гранулярный контроль.

Подготовка к Kubernetes

В Kubernetes все эти концепции обретают новую форму:

В следующей статье мы поднимем свой первый кластер Kubernetes и увидим, как эти настройки применяются на практике, используя инструменты аудита.

Практика Kubernetes: развертывание кластера и управление жизненным циклом приложений

Мы прошли долгий путь от изучения системных вызовов ядра Linux до написания безопасных Dockerfile. Теперь мы стоим на пороге оркестрации. В мире DevSecOps одиночный контейнер — это лишь атом. Молекулой является Pod, а организмом — Кластер Kubernetes.

В этой статье мы перейдем от теории к практике. Мы развернем локальный кластер, запустим в нем приложение, а затем, надев шляпу инженера по безопасности, проверим его на прочность с помощью инструментов аудита kube-bench и Trivy Operator.

Выбор инструментария: Почему Kind?

Для развертывания Kubernetes (K8s) существует множество способов: от сложного kubeadm на

Безопасность в K8s: аудит кластера через kube-bench и внедрение Trivy Operator

В предыдущих статьях мы прошли путь от низкоуровневых механизмов Linux (Namespaces, Cgroups) до создания безопасных Docker-образов и развертывания первого кластера Kubernetes. Теперь, когда наш кластер работает, возникает закономерный вопрос: насколько он безопасен?

Запуск приложения в Kubernetes без аудита безопасности похож на заселение в дом, где вы не проверили замки на дверях. В этой статье мы перейдем к практике DevSecOps внутри кластера. Мы научимся проводить автоматизированный аудит конфигурации с помощью kube-bench и внедрим непрерывное сканирование уязвимостей с помощью Trivy Operator.

Стандарты безопасности: CIS Benchmarks

Прежде чем использовать инструменты, нужно понять, что именно мы проверяем. В индустрии безопасности существует золотой стандарт настройки систем — CIS Benchmarks (Center for Internet Security Benchmarks).

Это объемные документы (часто более 200 страниц), описывающие лучшие практики настройки операционных систем, облачных провайдеров и, конечно же, Kubernetes. Они отвечают на вопросы:

* Какие права должны быть у файла конфигурации kubelet? * Нужно ли отключать анонимную аутентификацию на API-сервере? * Как часто должна ротироваться PKI-инфраструктура?

Вспомните нашу первую статью о правах доступа в Linux. CIS Benchmark для Kubernetes требует, чтобы критические файлы (например, /etc/kubernetes/admin.conf) имели права 600 (чтение/запись только владельцем) и принадлежали root:root. Если права будут 644, любой пользователь узла сможет прочитать ключи администратора и захватить кластер.

Аудит конфигурации с kube-bench

Проверять сотни пунктов вручную невозможно. Для этого компания Aqua Security разработала инструмент kube-bench. Это утилита на Go, которая проверяет ваш кластер на соответствие стандартам CIS.

Как работает kube-bench

Kube-bench запускается прямо на узлах кластера. Он анализирует:

[VISUALIZATION: Схема работы kube-bench. Слева изображен под kube-bench. От него идут стрелки к файловой системе хоста (Host Filesystem), проверяя файлы в /etc/kubernetes, и к списку процессов (Process List), проверяя флаги запуска kube-apiserver. Результат проверки выводится в виде отчета PASS/FAIL.]

Практический запуск

Самый простой способ запустить проверку в кластере — использовать Job (задачу). Поскольку kube-bench должен проверять файлы хоста, ему потребуется монтирование файловой системы узла и использование hostPID.

Пример манифеста job-kube-bench.yaml:

Обратите внимание на использование hostPath. В статье про Dockerfile мы говорили, что это опасно. Но в данном случае это необходимо для инструмента аудита. Это отличный пример того, когда нарушение правил безопасности оправдано целью защиты.

Анализ результатов

После выполнения задачи мы можем посмотреть логи:

Вывод будет содержать статусы: * [PASS] — Настройка соответствует стандарту. * [FAIL] — Найдено нарушение. Требуется исправление. * [WARN] — Требуется ручная проверка или настройка не применима.

Пример ошибки:

Kube-bench также подскажет, как это исправить (Remediation). В данном случае нужно отредактировать конфигурацию kubelet и перезапустить сервис.

Непрерывное сканирование: Trivy Operator

Kube-bench проверяет инфраструктуру. Но что насчет приложений, которые в ней работают? Мы могли просканировать Docker-образ на этапе CI/CD, но этого недостаточно.

Почему сканирования в CI мало?

Для решения этой задачи используется Trivy Operator.

Архитектура Trivy Operator

Оператор — это паттерн Kubernetes, который позволяет автоматизировать управление сложными системами. Trivy Operator работает внутри кластера и автоматически сканирует все новые и существующие поды.

Он использует CRD (Custom Resource Definitions) для хранения отчетов. Это значит, что результаты сканирования становятся обычными объектами Kubernetes, которые можно получить через kubectl.

[VISUALIZATION: Диаграмма архитектуры Trivy Operator. В центре находится Trivy Controller. Он следит (Watch) за новыми Pods. Когда появляется Pod, контроллер запускает Job (сканер). Результат сканирования записывается в объект CRD VulnerabilityReport, который привязан к Pod.]

Установка и использование

Установка обычно выполняется через Helm:

После установки оператор начнет наблюдать за кластером. Как только вы запустите любой под (например, nginx), Trivy Operator увидит это, запустит задачу сканирования и сформирует отчет.

Работа с отчетами (VulnerabilityReports)

Чтобы увидеть уязвимости вашего приложения, не нужно идти в отдельный веб-интерфейс. Достаточно выполнить команду:

Вывод покажет список отчетов для каждого контейнера. Чтобы увидеть детали:

Внутри YAML вы найдете секцию vulnerabilities, где перечислены CVE, их серьезность (Critical, High, Medium) и версии пакетов.

ConfigAuditReports

Помимо поиска CVE в образах, Trivy Operator проверяет манифесты Kubernetes на наличие небезопасных настроек (Misconfigurations). Он ищет то, о чем мы говорили в статье про Dockerfile:

* Запущен ли контейнер от root (runAsNonRoot: false)? * Есть ли опасные capabilities (CAP_SYS_ADMIN)? * Используется ли привилегированный режим (privileged: true)?

Эти отчеты доступны через другой CRD:

Интеграция процессов

Внедрение kube-bench и Trivy Operator позволяет построить замкнутый цикл безопасности:

Заключение

Безопасность Kubernetes — это не разовое действие, а процесс. Мы начали с настройки ядра Linux, научились собирать минималистичные образы и теперь внедрили инструменты автоматического аудита прямо в сердце нашей инфраструктуры.

Однако, даже самый защищенный кластер бесполезен, если мы не видим, что в нем происходит в реальном времени. В следующей части курса мы погрузимся в мониторинг и логирование, чтобы научиться обнаруживать атаки в момент их совершения, а не постфактум.

Организация мониторинга и наблюдаемости в Linux и распределенных системах

В предыдущих частях курса мы построили надежный фундамент: разобрали архитектуру Linux, научились создавать безопасные Docker-образы и развернули кластер Kubernetes, проверив его на соответствие стандартам CIS Benchmark с помощью kube-bench и Trivy.

Однако, даже идеально настроенная система не застрахована от сбоев или атак нулевого дня. Безопасность — это не состояние, а процесс. И этот процесс невозможен без наблюдаемости (Observability). Если вы не видите, что происходит внутри вашего кластера прямо сейчас, вы не сможете предотвратить инцидент.

В этой статье мы разберем, как операционная система отдает метрики, чем мониторинг отличается от наблюдаемости и как построить систему обнаружения угроз в реальном времени.

Отличия Мониторинга от Наблюдаемости

Часто эти термины используют как синонимы, но в инженерной культуре SRE (Site Reliability Engineering) между ними есть существенная разница.

Мониторинг отвечает на вопрос: «Здорова ли система?»* Он сообщает, когда что-то сломалось (например, «CPU usage > 90%» или «Сайт вернул 500 ошибку»). Наблюдаемость (Observability) отвечает на вопрос: «Почему это происходит?»* Это свойство системы, позволяющее понять её внутреннее состояние на основе внешних данных (логов, метрик, трейсов).

!Три столпа наблюдаемости, формирующие полное понимание работы системы.

Источники данных в Linux: /proc и /sys

Прежде чем устанавливать сложные системы вроде Prometheus, важно понять, откуда берутся данные. В Linux нет магии: вся информация о процессах и «железе» доступна через файловую систему.

Псевдо-файловая система /proc

Когда вы запускаете утилиту top или htop, они не обращаются к процессору напрямую. Они читают файлы в директории /proc. Это виртуальная файловая система, которая создается ядром в оперативной памяти.

* /proc/meminfo: Информация о памяти (используется командой free). * /proc/cpuinfo: Информация о процессоре. * /proc/[PID]/: Директория с информацией о конкретном процессе.

Попробуйте выполнить в терминале:

Вы увидите три числа. Это Load Average — средняя нагрузка на систему за 1, 5 и 15 минут. Понимание этих чисел критично для диагностики DoS-атак.

Математика надежности

В распределенных системах мы часто оперируем понятием доступности (Availability). Она рассчитывается на основе времени работы и времени простоя.

Где — доступность (вероятность того, что система работает в произвольный момент времени), (Mean Time Between Failures) — среднее время между сбоями, а (Mean Time To Repair) — среднее время восстановления после сбоя.

Задача DevSecOps инженера — максимизировать (через качественный код и тесты) и минимизировать (через быстрый мониторинг и автоматическое восстановление).

Три столпа наблюдаемости

1. Метрики (Metrics)

Метрики — это числовые данные, измеряемые во времени (Time Series Data). Они дешевы в хранении и отлично подходят для алертинга.

Золотой стандарт метрик (The Four Golden Signals от Google):

2. Логи (Logs)

Лог — это текстовая запись о событии. В отличие от метрик, логи тяжелые и их сложно агрегировать, но они содержат контекст. В Kubernetes стандартом является вывод логов в stdout/stderr. Контейнерный движок перехватывает эти потоки и сохраняет их в JSON-файлы на узле, откуда их забирают агенты (например, Fluentd или Promtail).

3. Трассировка (Tracing)

В микросервисной архитектуре один запрос пользователя может породить цепочку вызовов через 10 разных сервисов. Трейсинг (например, Jaeger или Tempo) позволяет визуализировать этот путь и найти, на каком этапе возникла задержка.

Prometheus: Стандарт де-факто в Kubernetes

Для сбора метрик в мире Cloud Native чаще всего используется Prometheus. Его архитектура отличается от классических систем мониторинга (как Zabbix или Nagios).

Pull Model vs Push Model

* Push (Zabbix, Graphite): Агент на сервере отправляет данные в центральное хранилище. * Pull (Prometheus): Сервер Prometheus сам приходит к приложению и забирает (скрапит) метрики по HTTP-эндпоинту (обычно /metrics).

!Pull-модель сбора метрик в экосистеме Prometheus.

Преимущество Pull-модели для безопасности: вам не нужно открывать исходящий доступ для каждого сервера в интернет или центральную сеть. Вы контролируете точку входа. Кроме того, если приложение «умерло», Prometheus сразу это заметит, так как не сможет забрать метрики.

Node Exporter

Сам по себе Linux не отдает метрики в формате Prometheus. Для этого используется Node Exporter — агент, который конвертирует данные из /proc и /sys в формат, понятный Prometheus.

Пример метрики:

Runtime Security: Когда Trivy недостаточно

В прошлой статье мы использовали Trivy для поиска уязвимостей в образах. Это называется Static Analysis (статический анализ). Но что, если злоумышленник использует уязвимость нулевого дня (Zero Day), которую сканер еще не знает?

Здесь на сцену выходит Runtime Security (безопасность времени выполнения). Инструменты этого класса следят за поведением приложения.

Falco

Falco — это «камера видеонаблюдения» для Kubernetes. Он работает на уровне ядра Linux, используя технологию eBPF (или модуль ядра), чтобы перехватывать системные вызовы (syscalls).

Вспомните первую статью курса: любое действие (открытие файла, запуск процесса, сетевое соединение) проходит через системный вызов. Falco видит их все.

Пример правила Falco, которое детектирует запуск оболочки внутри контейнера (классический признак взлома):

Если злоумышленник выполнит kubectl exec -it pod-name -- bash, Falco перехватит системный вызов execve, сопоставит его с правилом и отправит алерт в Slack или систему SIEM.

Практика: Мониторинг как код

В DevSecOps мониторинг настраивается так же, как и инфраструктура — через код.

Заключение

Мы замкнули цикл безопасности:

Теперь ваша инфраструктура не «черный ящик». Вы видите нагрузку, ошибки и попытки вторжения. Это и есть суть DevSecOps — безопасность, встроенная в каждый этап жизненного цикла, от написания кода до его исполнения в проде.