😎 Настоящий 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 на безопасность.

#полезное

🛡 Fail2ban — система предотвращения атак brute-force, которая мониторит логи служб и автоматически блокирует подозрительные IP-адреса.

🔵 Как работает

— Мониторит логи служб (SSH, Apache, Nginx) в реальном времени
— Обнаруживает подозрительные паттерны (многократные неудачные попытки)
— Добавляет временные блокировки в iptables/nftables
— Автоматически разблокирует IP после истечения таймаута

🔵 Основное использование

Установка:

# Ubuntu/Debian
sudo apt install fail2ban

# CentOS/RHEL
sudo dnf install fail2ban

Базовые команды:

sudo fail2ban-client status      # статус блокировок
sudo fail2ban-client reload      # перезагрузка конфигурации

Конфигурация для SSH (/etc/fail2ban/jail.local):

enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Параметры: 3 попытки за 10 минут → блокировка на 1 час

Пример фильтра для защиты от сканирования Nginx:

[nginx-404]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 300

📊 Мониторинг и управление

# Просмотр заблокированных IP
sudo fail2ban-client status sshd

# Разблокировка конкретного IP
sudo fail2ban-client set sshd unbanip 192.168.1.100

# Блокировка конкретного IP
sudo fail2ban-client set sshd banip 192.168.1.120

🔵 Особенности

— Поддерживает различные бэкенды (iptables, nftables, firewalld)
— Гибкая настройка фильтров через регулярные выражения
— Возможность отправки уведомлений по email
— Интеграция с systemd journal

Fail2ban — первый рубеж обороны для любого интернет-экспонированного сервиса. Не заменяет комплексные системы безопасности, но эффективно отсекает базовые атаки перебором.

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

🛡 Администрирование системы защиты SELinux

Практическое руководство по тому, как превратить SELinux из «мешающего демона» в управляемый и предсказуемый инструмент защиты Linux-систем — от базовой настройки до тонкой доработки политик под вашу инфраструктуру.

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

— место SELinux среди стандартных механизмов безопасности Linux и его ключевые преимущества;
— базовая архитектура и включение SELinux, разбор логов и диагностика типичных ошибок;
— настройка и тюнинг политик доступа для файлов, процессов и сетевых сервисов;
— защита виртуализации и контейнеров (libvirt/sVirt, Docker) на практике;
— как писать и дорабатывать свои политики SELinux вместо того, чтобы отключать его.

Полезно администраторам Linux, инженерам эксплуатации, DevOps- и инфраструктурным командам, специалистам по информационной безопасности и архитекторам, которым важно системно повысить защищенность Linux-инфраструктуры и при этом сохранить устойчивость бизнес-сервисов.

Автор:
Свен Вермейлен.
Издательство:
ДМК Пресс, рус. изд., Москва, 2020.

#книги

🔎 Kubesec — утилита для Kubernetes, которая проверяет YAML-манифесты на рискованные настройки безопасности и возвращает score + список сработавших правил.

Инструмент помогает быстро находить небезопасные параметры (capabilities, root, privileged, отсутствие securityContext и т.д.) ещё до деплоя — локально или в CI/CD.

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

— анализ манифестов (Deployment/Pod/DaemonSet и др.) с оценкой риска (score)
— детальный JSON-отчёт: что именно не так и почему
— просмотр правил оценки (за что начисляются/снимаются баллы)
— режим HTTP-сервиса: можно отправлять YAML на / scan
— интеграция в CI/CD: возможность блокировать сборку при низком score
— есть публичный endpoint, но чувствительные манифесты лучше не отправлять наружу (поднимать локально)

👉 Git
#полезное