💎 Chaos Mesh — платформа хаос-инжиниринга для Kubernetes.

Позволяет моделировать отказы и оркестровать сценарии через CRD и удобную веб-панель (Chaos Dashboard).

⚙️ Основной функционал:

— Типы экспериментов: PodChaos, NetworkChaos, IOChaos, TimeChaos, DNSChaos, StressChaos, KernelChaos, а также облачные сбои.

— Оркестрация сценариев через Chaos Workflows, в том числе проверки статуса и последовательности шагов.

— Управление через Kubernetes API/kubectl и Web-UI; все сущности оформлены как CRD.

— Безопасность: ограничение пространств имён, аутентификация, admission-webhook и RBAC-контроль.

— Интеграции: GitHub Actions (chaos-mesh-action) для запуска экспериментов в CI.

— Установка через Helm-чарт

Полезно для проверки устойчивости сервисов к сбоям до продакшена и выявления «узких мест» инфраструктуры.

👉 Git
#полезное

📊 Мониторинг системных метрик в Linux

В Linux есть встроенные утилиты для анализа в реальном времени

↗️ Что и чем смотреть

— top / htop: Мониторинг процессов, CPU, памяти в реальном времени.
— iostat: Статистика ввода-вывода (диски, I/O bottlenecks).
— vmstat: Виртуальная память, CPU, процессы (общая нагрузка).
— netstat / ss: Сетевые соединения, порты, статистика трафика.

↗️ Основное использование:

🟡 top: Интерактивный мониторинг процессов.

top # запуск, Shift+P для сортировки по CPU, Shift+M по памяти q для выхода.

🟡 htop: Улучшенный top с цветами, мышью и деревом процессов.

htop # аналогично top, но удобнее;

🟡 iostat: I/O статистика по дискам.

iostat -x 1 5 # расширенный вывод, интервал 1с, 5 итераций

(показывает %util — загрузку дисков, await — время отклика).

🟡 vmstat: Краткий обзор системы.

vmstat 1 5 # интервал 1с, 5 итераций

(показывает r/b — процессы в очереди/блоке, swpd — swap, si/so — swap in/out).

🟡 netstat / ss: Сетевые соединения.

netstat -tuln # TCP/UDP listening порты
ss -tuln # аналог netstat
ss -tp 'state established' # активные TCP-соединения с процессами.

Эти утилиты — первый инструмент при любой диагностике проблем с производительностью. Не заменяют полноценные системы мониторинга, но дают мгновенную картину происходящего в системе.

#линуксятина

⏰ Site Reliability Engineering — набор инженерных практик для стабильного сервиса, предсказуемых рисков и затрат.

➡️ Функции SRE влияют на ключевые показатели:
SLA/SLO — обещанная и целевая доступность;
MTTR/MTBF — скорость восстановления и частота отказов;
RTO/RPO— время восстановления и допустимые потери данных при аварии;
TCO— совокупная стоимость владения.

Разберём их в виде глоссария:

🟢SLI/SLO/SLA

Фиксирует качество сервиса в числах: доступность, ошибки, время ответа.

*обеспечивает выполнение обязательств, снижает штрафы и споры, задаёт понятные приоритеты.

🟢Incident Response

Стандартизирует действия во время сбоя.

*сокращает MTTR, уменьшает потери выручки и репутации, помогает удерживать SLA/SLO.

🟢 Postmortem

Фиксирует, что произошло, почему это случилось и что нужно изменить, чтобы больше не повторилось.

* уменьшает повторные сбои и риски, повышает надёжность сервиса и накапливает знания для аудита и обучения.

🟢Observability

Диагностирует неизвестные проблемы через исследование метрик, логов и трейсов.

* уменьшает время диагностики, поддерживает достижение SLO, убирает «слепые зоны».

🟢 Progressive Delivery

Проводит поэтапный вывод обновлений с контролем трафика и быстрым откатом при проблемах.

* снижает релиз-инциденты, сокращает MTTR, уменьшает стоимость сбоев.

🟢 HA и DR

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

* предсказуемые RTO/RPO, соблюдение требований, меньше простоев и ниже TCO.

🟢Автоматизация и runbook-и

Стандартизирует и автоматизирует типовые операции: перезапуск, откат, переключение трафика и т.д.

*сокращает MTTR и операционную рутину (toil), обеспечивает предсказуемые результаты.

🟢Chaos Engineering

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

*снижает частоту и длительность сбоёв, помогает удерживать SLA/SLO, уменьшает незапланированные расходы.

🟢 Управление toil

Измеряет повторяющиеся ручные задачи и устраняет их.

*высвобождает время инженеров на улучшения и фичи, уменьшает TCO.

#полезное

😎 Настоящий SRE: инжиниринг надежности для специалистов и организаций

Практическое руководство по тому, как мыслить, работать и строить команды в парадигме SRE, отвечающие за надежность современных сервисов.

🔎 Рассматривается:

— что такое SRE, чем оно отличается от DevOps и классической эксплуатации;
— менталитет SR-инженера: системное мышление, фокус на клиенте, работа с инцидентами и обратной связью;
— культура SRE и «продвижение» надежности внутри компании;
— как стать SR-инженером: переход из разработки, админства, нетехнических ролей, поиск работы и собеседования;
— один день из жизни SR-инженера, рутина, борьба с выгоранием и устойчивые рабочие практики;
— факторы успеха и типичные провалы при внедрении SRE в организации;
— иерархия надежности Дикерсона, модели команд SRE и этапы развития практики SRE в компании;
— дополнительные ресурсы, письма «молодому SRE» и советы от опытных практиков.

Полезно начинающим и действующим SR-инженерам, DevOps- и платформенным командам, инженерам эксплуатации, техлидам и руководителям ИТ, которые хотят системно подойти к надежности и выстроить зрелую практику SRE в своей организации.

Автор:
Дэвид Н. Бланк-Эдельман.
Издательство:
O’Reilly / «Спринт Бук», рус. изд., 2025.

#книги

🚂 sl: поезд вместо ls

sl — консольная утилита, которая запускает анимацию паровоза в ASCII-графике, когда вы вместо ls набираете sl .

👍 Это исторический Unix-розыгрыш: его придумали, чтобы «наказывать» вечных опечатывающихся.

Работает как обычная команда:
ввёл sl — поехал поезд, терминал на пару секунд превращается в анимированный скринсейвер.

😈 Можно развлечь своих коллег.

⌨️ Установка

# Debian / Ubuntu
sudo apt install sl

# Fedora
sudo dnf install sl

# Arch / Manjaro
sudo pacman -S sl

P.S. хороших выходных ☺️

#rootoffun

⚖️ Изменения в законодательстве для ИТ

📝 Увеличен срок хранения данных пользователей: мессенджеры, соцсети и другие сервисы (организаторы распространения информации) должны будут хранить их не 1 год, а 3. Это правило начнёт действовать с 1 января 2026 года.

📝 Госаккредитация ИТ-компаний с 2026 года будет зависеть от того, открыт ли их официальный сайт для любого посетителя: без регистрации, паролей и ввода личных данных.

📝 Налоговые льготы для ИТ-компаний пересматриваются: планируется повысить льготный тариф страховых взносов и частично изменить льготы по НДС для операций с российским ПО. Окончательный текст закона пока не утверждён.

📝 Штрафы от 10 до 500 тыс.₽ предлагают ввести за размещение видео, созданных с помощью ИИ, если они не помечены соответствующей маркировкой. Соответствующий законопроект уже внесён в Госдуму.

#ИТиЗАКОН

📦 Три типа хранилища

Наглядная схема от ByteByteGo.

➡️ Блочное хранилище (Block Storage)

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

Подходит для задач, когда:

— требуются высокие IOPS и низкая задержка;
— нужно хранить данные СУБД;
— разворачиваются диски виртуальных машин и другие критичные транзакционные сервисы.

➡️ Файловое хранилище (File Storage)

Поверх блоков поднимается файловая система с привычной моделью «папки/файлы», доступной по сети (NFS, SMB).

Подходит для задач, когда:

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

➡️ Объектное хранилище (Object Storage)

Данные хранятся в виде отдельных объектов в общем пространстве, без привычных папок. Доступ к ним идёт через API (часто S3-совместимый). Такой подход делает упор на большой масштаб, надёжность и низкую стоимость, а не на максимальную скорость.

Подходит для задач, когда:

— нужны недорогие и надёжные объёмы хранения на терабайты и выше;
— требуется хранить бэкапы, архивы, статику и медиа;
— накапливаются данные для аналитики и построения data lake.

#полезное

👋 Инструменты для Argo CD

Экосистема инструментов вокруг Argo CD

🟠 Argo CD Autopilot
— инструмент для быстрого развертывания и управления ArgoCD по принципу "GitOps для самого ArgoCD".

🟠 Argo CD Image Updater
— инструмент для автоматического обновления образов в приложениях ArgoCD до последних версий.

🟠 Argo Rollouts
— расширение для управления постепенным развертыванием (canary, blue-green) в Kubernetes.

🟠 Make-argocd-fly
— Превращает шаблоны на базе Helm, Kustomize и Jinja2 в Kubernetes-манифесты, а также автоматически создает ресурсы Argo CD Application, адаптированные для разных окружений

#полезное

⭐️ Инструменты для FluxCD

Экосистема инструментов вокруг FluxCD

🔵 Flagger
— оператор для автоматизации canary-релизов в Kubernetes, часто используемый с FluxCD.

🔵 Weave GitOps
— корпоративная платформа GitOps на основе Flux с веб-интерфейсом, RBAC и расширенной аналитикой.

🔵 FluxCD Multi Tenancy
— инструмент для организации мультитенантной работы в FluxCD, позволяющий изолировать команды и среды в рамках одного кластера.

🔵 Terraform Provider for Flux
— официальный Terraform провайдер для развертывания и управления FluxCD через Infrastructure as Code.

#полезное

💎 Конец эры Ingress NGINX

В блоге Kubernetes объявили о поэтапном завершении поддержки Ingress NGINX.

📍 Что такое Ingress в K8s

Ingress — это Kubernetes-ресурс, который описывает, как внешний HTTP/HTTPS-трафик попадает к сервисам внутри кластера: хосты, пути, TLS, балансировка нагрузки.
Без него каждый сервис приходится выводить наружу через NodePort или отдельный LoadBalancer, что быстро становится неудобно в production.

Сам по себе Ingress — это только декларация. Работу за него делает Ingress-контроллер: отдельный компонент, который отслеживает создание и изменение Ingress-ресурсов через Kubernetes API и на их основе настраивает прокси или балансировщик (NGINX, Envoy, HAProxy и т.п.).

📍 Что такое Ingress NGINX

Ingress NGINX — это один из таких контроллеров. Он использует NGINX, парсит Ingress-ресурсы и генерирует для него конфигурацию.

Его массово выбрали как «дефолтное» решение за счёт:

— простого старта;
— хорошей производительности;
— богатого набора функций (rate limiting, авторизация, тонкая настройка через аннотации).

📍 История проблемы

Ingress NGINX давно жил в режиме «минимально достаточной поддержки». На фоне высокой популярности проект сталкивался с одними и теми же ограничениями:

— мало мейнтейнеров,
— сложная кодовая база,
— растущий backlog issues и PR.

Решение о завершении поддержки — логический итог этого накопившегося технического и организационного долга.

📍 Что происходит сейчас

— Поддержка Ingress NGINX заявлена до марта 2026 года.
— До этого момента будут выходить критические обновления безопасности.
— Текущие развёртывания продолжают работать в прежнем режиме.
— Образы контейнеров, Helm-чарты и другие артефакты остаются доступными.

#заметкиИнженера

➡️ Чем заменить Ingress NGINX?

Обзор альтернативных контроллеров на замену Ingress NGINX

📍 Gateway API — развивается как преемник классического Ingress и более гибкий способ описания сетевого трафика в кластере.

По сравнению с Ingress он:

— поддерживает более сложные сценарии маршрутизации (canary, A/B-тесты и др.);

— вводит чёткое разделение ролей между инфраструктурой и приложениями;

— становится отраслевым стандартом, который поддерживают разные вендоры и open source-проекты.

📍 Traefik Proxy

— динамическая конфигурация без перезапуска;
— встроенный dashboard для мониторинга и отладки;
— поддержка нескольких протоколов (HTTP, TCP, gRPC, WebSocket).

📍 HAProxy Ingress Controller

— высокая производительность и предсказуемое поведение под нагрузкой;
— развитые возможности балансировки и тонкая настройка;
— подробные метрики для интеграции с системами мониторинга.

📍 Контроллеры на базе Envoy: Contour, Emissary-ingress

— расширенные возможности для интеграции с service mesh;
— гибкая конфигурация через xDS-API;
— активное развитие и поддержка со стороны сообщества и вендоров.

📍 Что учитывать при выборе?

— Сложность миграции с существующих конфигураций Ingress NGINX
— Поддержка Gateway API — становится ключевым критерием
— Производительность под вашу нагрузку
— Экосистема и сообщество вокруг проекта

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

#полезное

⚙️ Fio (Flexible I/O Tester)
— мощная утилита для бенчмаркинга и стресс-тестирования систем хранения. Она стала стандартом для измерения реальной производительности дисков, SSD и массивов хранения.

✔️ Что умеет?

— Тестирование различных паттернов доступа (seq/random read/write)
— Поддержка синхронных и асинхронных операций ввода-вывода
— Работа с разными блочными размерами и глубиной очереди
— Эмуляция реальных рабочих нагрузок (базы данных, файловые серверы)
— Детальная статистика по задержкам и пропускной способности

✔️ Ключевые параметры:

--rw: режим операции (read, write, randread, randwrite, randrw)
--bs: размер блока (например, 4k, 1M)
--size: общий объем данных для операции
--runtime: длительность теста в секундах
--numjobs: количество параллельных задач
--ioengine: механизм I/O (libaio, sync, io_uring)
--filename: файл или устройство для тестирования

✔️ Основное использование:

Базовый тест последовательной записи:

fio --name=seq_write --rw=write --bs=1M --size=1G --filename=./testfile

Тест случайного чтения (4K, типично для БД):

fio --name=rand_read --rw=randread --bs=4k --size=1G --filename=./testfile

Многопоточный тест с глубиной очереди:

fio --name=multithread --rw=randrw --bs=4k --numjobs=4 --iodepth=32 --size=1G --filename=./testfile --group_reporting

✔️ Ключевые метрики в отчёте:

— BW (Bandwidth) — пропускная способность (MB/s)
— IOPS — операции ввода-вывода в секунду
— latency — задержки (min, max, avg, 95th percentile)
— slat/clat — задержки на уровне системы и устройства

Вместо расплывчатого значения «диск медленный» fio показывает конкретные цифры: скажем, 1500 IOPS при random read 4K с задержкой 15 ms. По этим данным уже можно предметно искать проблемы в хранилище и сравнивать производительность разных систем.

#линуксятина

🤓 Высоконагруженные приложения. Программирование, масштабирование, поддержка

Подробное руководство о том, как проектировать и развивать системы, работающие с большими объёмами данных: от выбора моделей и хранилищ до надёжной распределённой архитектуры.

🔎 Рассматривается:
— что такое data-intensive приложения и базовые требования к надёжности, масштабируемости и сопровождаемости;
— модели и хранение данных: реляционные, документные, графовые БД, внутреннее устройство движков, индексы, журналы, структуры данных вроде B-деревьев и LSM-деревьев;
— распределённые системы: репликация, шардирование, транзакции, согласованность, консенсус и компромиссы CAP/PACELC;
— обработка данных: batch- и stream-подходы, события и лог, конвейеры на базе Hadoop, Spark, Kafka, Flink;
— архитектурные решения: как трезво оценивать инструменты, читать документацию и строить системы, устойчивые к росту нагрузки и сбоям.

Полезно бэкенд-разработчикам, инженерам данных, архитекторам, DevOps- и платформенным командам, тимлидам и техническим руководителям, которые принимают решения о том, какие БД, брокеры и пайплайны данных использовать и как связать всё это в цельную систему.

Автор:
Мартин Клеппман.
Издательство:
СПб.: Питер, 2018. серия «Бестселлеры O’Reilly».

#книги

🦩 Argo CD или Flux?

Можно не выбирать, а использовать лучшее из двух решений!

➡️ Flamingo (Flux Subsystem for Argo)

Это пропатченный образ Argo CD, в котором под капотом работает Flux, а интерфейс и модель работы остаются на стороне Argo CD.

В этой связке Argo CD остаётся точкой входа и наблюдения за состоянием, а Flux отвечает за синхронизацию манифестов с кластером.

🟣 Что даёт такой подход инженерам:

— использование HelmRelease из Flux с визуализацией и управлением через Argo CD;

— поддержка OCI Repository и других возможностей, доступных только во Flux;

— интеграция Weave GitOps Terraform Controller — Terraform-вызовы становятся частью единой GitOps-цепочки;

— доступ к Flux-ресурсам (Kustomization, HelmRelease, Source и др.) напрямую из Argo CD, без переключения между несколькими инструментами.

🟣 Когда имеет смысл использовать Flamingo:

— инфраструктура уже управляется через Argo CD, но требуется функциональность Flux;

— нежелательно вводить отдельный дашборд ради HelmRelease, OCI или Terraform-контроллера;

— используется или планируется мультикластерный ландшафт и нужен максимально централизованный контроль.

#полезное

🤯 «Нас взломали!
На главной странице сайта висит реклама онлайн-казино. Подскажи что делать?»

Такое сообщение прилетело в личку одному нашему сотруднику отдела ИБ.

Безопасник зашел на сайт и сразу обнаружил проблему:
страница входа в админку висит в открытом доступе.

🤦‍♂️ Учётку просто забрутфорсили!

Никакой магии и сложных схем взлома — админка не спрятана, защита минимальная, пароль подобрали...

А ваши админки спрятаны?

P.S.👋С понедельником

⚠️ Типы атак на пароли

🔴 Атака на автозаполнение браузера (Browser Autofill Exploit)

— извлечение учётных данных, сохранённых в функции автозаполнения браузера.

🔴 Атака перебором / грубая сила (Brute Force Attack)

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

🔴 Атака повторным использованием учётных данных (Credential Stuffing)

— попытки входа на разные сервисы с логинами и паролями из ранее известных утечек.

🔴 Словарная атака (Dictionary Attack)

— подбор паролей по заранее подготовленному словарю распространённых слов и типовых комбинаций.

🔴 Атака на коллизии хэша (Hash Collision Attack)

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

🔴 Кейлоггинг (Keylogging)

— скрытая запись нажатий клавиш для перехвата пароля в момент ввода.

🔴 Атака посредника (Man-in-the-Middle Attack)

— перехват и возможная подмена трафика между пользователем и сервисом для кражи учётных данных.

🔴 «Распыление» паролей (Password Spraying)

— проверка ограниченного набора популярных паролей сразу на множестве аккаунтов, чтобы снизить риск блокировки.

🔴 Фишинговая атака (Phishing Attack)

— выманивание пароля с помощью поддельных сайтов, писем или сообщений, маскирующихся под легитимные.

🔴 Атака с использованием радужных таблиц (Rainbow Table Attack)

— применение заранее вычисленных таблиц соответствия хэшей и исходных паролей для их быстрого восстановления.

🔴 Подсматривание через плечо (Shoulder Surfing)

— наблюдение за пользователем при вводе пароля визуально или с помощью камер.

🔴 Социальная инженерия (Social Engineering)

— манипуляции и обман, чтобы человек добровольно раскрыл пароль или другие конфиденциальные данные.

#проИБ #полезное

🛡 Четыре слоя защиты конфиденциальных данных

Конфиденциальные данные — это не только ПДн.
Под защитой — финансовая информация (счета, карты, отчёты), медицинские сведения, интеллектуальная собственность (чертежи, код, проекты), данные об обучении и работе, юридические документы и любые другие данные, за которыми готовы охотиться киберпреступники.

➡️ Шифрование и управление ключами

HTTPS по умолчанию, пароли только в виде хеша + salt, ключи — в KMS с раздельными ролями (заявитель, менеджер, аудитор).

🟢 Помогает, когда:
— есть внешние интеграции и удалённый доступ;
— нужно закрыть требования регуляторов.

➡️ Десенсибилизация данных
Анонимизация, маскирование, псевдонимизация — убираем прямые идентификаторы и разделяем пользовательские данные и ключи.

🟢 Помогает, когда:
— делимся данными с подрядчиками и внешними командами;
— даём аналитикам доступ к данным без «живых» ПДн.

➡️ Минимальные права доступа (RBAC)

Роли заданы, доступ выдаётся по принципу минимально необходимого, а не «на всякий случай».

🟢 Помогает, когда:
— в системе много пользователей и сервисных аккаунтов;
— важно быстро понять, кто к каким данным имеет доступ.

➡️ Управление жизненным циклом данных

От заявки на доступ до продакшена: на dev/test — временные расширенные права, после запуска — пересмотр и отзыв.

🟢 Помогает, когда:
— нужно поддерживать качество данных и при этом не раздавать вечные доступы;
— важно отслеживать, кто и когда работал с конфиденциальной информацией.

#полезное

🪙 Кейс: Защита онлайн-сервиса от кибератак с помощью WAF CORTEL

Цель — сохранить непрерывность работы финансового сервиса и защитить его от целенаправленных сложных атак.

📞 Задача

— Обеспечить стабильную работу высоконагруженного веб-сервиса в режиме 24×7 без простоев.
— Усилить базовую защиту от DDoS для отражения сложных, целевых атак на веб-приложение.
— Минимизировать риски утечки персональных данных клиентов и регуляторных претензий.
— Внедрить решение без закупки «железа» и развёртывания собственной инфраструктуры.

⭐️ Этапы реализации

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

🚩 Результат

— 0 минут простоя бизнес-критичных сервисов из-за кибератак.
— 100% доступность сервиса для легитимных пользователей даже в периоды атак.
— Усиленная защита от целевых и сложных атак на веб-приложения без увеличения собственной ИТ-инфраструктуры.
— SLA на сервис защиты и оперативное расширение функциональности по запросу заказчика.
— Персональный менеджер и техподдержка 24×7, быстрые реакции на инциденты и изменения в профиле угроз.

«После внедрения WAF мы стали увереннее в устойчивости сервиса: атаки не приводят к простоям, а риски для клиентов и бизнеса контролируемы», — директор по ИБ ВебЗайм.

➡️ Подробнее о проекте читайте здесь.

➡️ О защите веб-приложений — здесь.

#изПрактик

🎙 Вебинар про инфраструктуру и безопасное размещение ИСПДн

За последние месяцы всё чаще сталкиваемся с вопросами про размещение ИСПДн:
что можно, что нельзя, где проходит граница ответственности, если вы отдаёте данные наружу, как проходят проверки и почему у одних компаний всё запускается за неделю, а у других — превращается в бесконечный проект.

Поэтому делаем открытый вебинар, где спокойно и по делу разберём всё, что важно знать перед построением архитекруты или миграцией в облако под ФЗ-152.

🗓 Когда:
3 декабря
11:00 по МСК

🎙 О чём поговорим:
— Когда можно использовать облако для ИСПДн.
— Что такое аттестованный ЦОД и почему это важно.
— Как распределяются зоны ответственности.
— Типовые ошибки при организации инфраструктуры.
— Как проходит аттестация ИС в облаке.
— Какие документы нужны между сторонами, чтобы избежать штрафов и переделок.
— Как выбрать решение: реальные примеры и ключевые отличия.
— Как построить защиту с нуля: аудит, документы, модель угроз, ТЗ, проект, аттестация.
— Практические кейсы.

Ссылка на регистрацию тут.

Если тема актуальна — не пропустите 😊

🛡💻 Security Context в Kubernetes: контроль прав подов и контейнеров

Набор настроек, определяющих права доступа и ограничения для Pod и Container.

Эти настройки реализуют принцип наименьших привилегий и предотвращают несанкционированный доступ.

💬 Зачем это нужно?

— Ограничить права контейнеров (принцип наименьших привилегий)
— Предотвратить доступ к ресурсам узла
— Соответствовать требованиям безопасности и compliance
— Защититься от escape-атаки из контейнера

💬 Основные настройки

На уровне Pod:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsNonRoot: true    # Запрет запуска от root
    runAsUser: 1000       # UID для запуска
    runAsGroup: 3000      # GID для запуска  
    fsGroup: 2000         # GID для томов
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

На уровне Container:

containers:
- name: sec-ctx-demo
  image: nginx
  securityContext:
    allowPrivilegeEscalation: false  # Запрет повышения привилегий
    capabilities:
      drop: ["ALL"]                  # Удаляем все capabilities
      add: ["NET_BIND_SERVICE"]      # Добавляем только нужные
    readOnlyRootFilesystem: true     # ФС только для чтения
    seccompProfile:
      type: RuntimeDefault           # Стандартный seccomp профиль

💬 Ключевые параметры безопасности:

— runAsNonRoot — гарантирует не-root выполнение
— readOnlyRootFilesystem — защита от модификации системы
— allowPrivilegeEscalation — блокировка повышения прав
— capabilities — тонкий контроль Linux capabilities
— seccompProfile — фильтрация системных вызовов

💬 Security Context — это базовый инструмент для security-in-depth в Kubernetes. Он не заменяет сетевые политики и Pod Security Standards, но создаёт фундамент для безопасной работы приложений.

Подробнее про Pod Security Standards и конфигурации Security Context для подов или контейнеров в официальной документации kubernetes.

#заметкиИнженера

🪖 Безопасность Kubernetes

Подборка инструментов

💬 kube-bench
— инструмент для проверки кластера Kubernetes на соответствие стандартам CIS Benchmark.

💬 Kyverno
— native-инструмент для управления политиками безопасности Kubernetes без необходимости изучения Rego.

💬 Sigstore
— набор инструментов для безопасной поставки ПО, включая подпись образов, прозрачный журнал и верификацию.

💬 Falco
— система runtime-безопасности для детекции аномального поведения в контейнерах и хостах.

💬 Checkov
— статический анализатор для инфраструктуры как код, проверяющий конфигурации Kubernetes, Terraform и CloudFormation на безопасность.

#полезное