Как встроить безопасность в свои процессы?

➡️ 4 июня в 19:00 мск — бесплатный вебинар с экспертами Kaspersky и Positive Technologies.

🔹 Dev vs Sec: всё ещё не разговаривают — почему?
🔹 Что DevSecOps может, а что не может?
🔹 Где DevSecOps реально помогает бизнесу, а где мешает?
🔹 Time to market — вечная басня, которая не про DevSecOps
🔹 Где в DevSecOps сейчас Ops, если DevSecOps это AppSec?

Ссылка на трансляцию придёт в бота в день вебинара. Занимайте места в первом ряду!

А пока ждёте — пройдите короткий тест из 5 вопросов и узнайте, насколько ваша команда готова к DevSecOps.

➡️ Подробности — в боте.

«Kubernetes для разработчиков» стартовал!🐈

Ближайшие 7 недель мы с коллегами будем учить студентов:

➡️ создавать и настраивать CronJob в Kubernetes, контролировать частоту выполнения задач;

➡️ устанавливать ограничения на перезапуск подов и задавать тайм-ауты на выполнение задач;

➡️ создавать и конфигурировать Service и Ingress для различных Deployment;

➡️ деплоить в Kubernetes, управлять переменными окружения контейнера и работать с логами подов, сохраняя их на указанные пути;

➡️ создавать и настраивать Helm-чарты для приложений, включая интеграцию с Redis через PersistentVolumeClaim;

➡️ настраивать CI/CD пайплайн в GitLab для автоматического билда, пуша образов и деплоя приложения в кластер Kubernetes.

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

Присоединиться можно до конца недели. Подробности — по ссылке.

k8s и бородатая база: сеть и unix

Ситуация:

➡️ Вы развернули on-premise кластер. Никаких managed сервисов в облаке, где можно одной кнопкой нарастить ноды, если вдруг лень освоить Terraform или другие инструменты IaC.

➡️ Внезапно нода отказывается регистрироваться в кластере. В логах тишина (кстати, в каких логах? компонентов-то много, которые логи пишут), kubectl get nodes показывает, что нода «NotReady». Что делать?

Помните времена dial-up модемов и админов, рулящих правилами iptables через /etc/rc.local (на или через другие init скрипты)? Но сегодня у нас есть k8s, виртуализация и прочие абстракции, призванные упростить нашу жизнь при работе at scale (или нет).

Знание UNIX-like систем — это база! k8s построен поверх базовых вещей: демонов, процессов, файловой системы, сетевых взаимодействий, сертификатов и так далее. Например, kubelet, может запускаться как systemd unit, и если у вас on prem кластер, умение продебажить проблемы на уровне linux может в редких случаях пригодиться.

➡️ Возвращаясь к ситуации выше — вот, какие есть варианты решения:

Вариант 1 (без solid знаний UNIX и сети)

Панически перезапускаем все подряд, молимся, обновляем k8s до последней версии (а вдруг поможет!).

Вариант 2 (с solid знаниями UNIX и сети)

🟠 Проверяем системные логи на ноде.
journalctl -u kubelet -f

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

🟠Смотрим конфигурацию kubelet.
cat /var/lib/kubelet/config.yaml . Мало что там понимаем 😂, но главное, посмотрели с умным видом.

🟠 Анализируем сетевую конфигурацию ноды.
ip addr show, ip route show, iptables -L (или nft list ruleset, если у вас современный дистрибутив). Убеждаемся, что сеть настроена правильно, что трафик между воркер нодой и мастер нодой не блокируется, что DNS резолвится корректно.

🟠Проверяем SELinux/AppArmor. Эти системы безопасности могут блокировать доступ kubelet к необходимым ресурсам. ausearch -m AVC -ts recent может помочь выявить проблемы.

🟠Не забываем про файрвол! Возможно, файрвол на ноде блокирует трафик от kubelet к kube-apiserver. Может быть вы разворачиваете ноды через ansible и где-то была внесена правка в переменных, из-за которых для всех новых настраиваемых нод файрвол неожиданно подкидывал начал подкидывать правила, которые вообще не для k8s нод предназначались.

И вот, спустя часы копания в логах вы докопались до причины.

Всегда виноват DNS (или сертификаты).

➡️ В продолжение вчерашнего поста — реальный кейс из практики.

Представьте, что есть внутренний DNS сервер, который автоматически регистрирует новые (и старые, конечно) серверы. Как - непринципиально. Хоть статикой через ansible, хоть через consul dns, хоть через любые другие велосипеды🚴

На новый сервер для новой k8s ноды так же через ansible все раскатили, но kubelet не хочет регистрироваться — ошибка сертификата. При этом DNS адрес API сервера правильный. Чудеса. IP адрес все равно никто не смотрел.

Long story short: в сети, без какой-то сегментации и с общим dns сервером оказалось 2 k8s кластера. Просто второй по ошибке частично раскатили «поверх» первого, подменив dns запись до API сервера (перезаписав в DNS сервере). Ну а кешировать DNS записи можно и на сутки, так что другие ноды вполне продолжали работать до поры до времени.

Все работает. Пока не перестанет.

➡️ Что почитать, чтобы получить более основательные знания сетей?

1. Таненбаум, «Компьютерные сети»
Он известен еще и тем, что создал minix — учебную ОС для изучения студентами. А так же как человек, активно споривший с Линусом Торвальдсом по поводу дизайна ядра Linux в далеком 1992, когда Торвальдс только начинал писать linux.

2. «Сети для самых маленьких»
Более простой путь, без погружения в преобразование Фурье.

Вопрос на подумать: к каким проблемам приведет mismatch MTU на api server и kubelet для on prem инфраструктуры? Пишите в комментариях ⬇️

Всем тем, кто прохавал YAML с самого низа, посвящается.

Если вы имеете дело с k8s и считаете, что YAML — это простой язык, обязательно прочитайте легендарный «YAML document from hell», откроете для себя много нового.

Тем, кто уже читал — мое почтение🎩

Ещё парочка полезных советов:

🟣 YAMLLint — чтобы автоматизировать проверки и не наступать на грабли.

🟣 Kubernetes для разработчиков — чтобы научиться правильно разрабатывать приложение под k8s и запускать его в кластере. До 2 июня при покупке тарифа «видеокурс» — 6 встреч с обратной связью в подарок.

➡️ Подробности — на странице курса ⬅️

Мы с котом ведем этот канал уже почти полгода 🔥

И пока Маркус преисполняется RHСP (ставьте 😻, если нужно больше постов с ним), я собрал для вас дайджест самых мясных материалов за всю историю моего присутствия здесь. Погнали!

➡️ Как работают requests/limits изнутри

➡️ Используем Sidecar Pattern во благо.
→ Часть 1
→ Часть 2

➡️ Что лежит в основе работы service mesh, и как нам в этом поможет Linux?

➡️ План онбординга в компанию
→ Часть 1
→ Часть 2
→ Часть 3

➡️ Типичные ошибки найма

➡️ Secret injection webhook

➡️ Как изучать новое с пользой и с доставкой прямо в ваш inbox?

➡️ CRI, CSI, CNI

➡️ Align expectations: почему это ключ к успеху почти в любой задаче

➡️ Собесы с алгоритмами — это лишь входной фильтр!
→ Часть 1
→ Часть 2

➡️ Роли в технических командах: запись прямого эфира
→ YouTube
→ VK Видео
→ Rutube
→ Дзен

➡️ API, за которые не стыдно

➡️ Ностальгии пост: с днем рождения, ETHERNET!

➡️ k8s и бородатая база: сеть и unix

В комментариях к этому посту можно свободно делиться своими мыслями о контенте, который я выкладываю, и писать пожелания для будущих публикаций ⬇️

Все уже слышали про вайб-кодинг

А что насчет вайб infrastructure as code? Мой опыт пока такой: модель легко создаст несуществующие опции, но если понимать, что она сгенерировала чушь, это можно легко поправить.

Гораздо опаснее, когда моделям дают доступ к инфре. Удобно, когда можно текстом описать желаемое (scale my k8s cluster by 10%), но делать так все же не стоит.

➡️ Есть другие применения AI. Например, мне довелось попользоваться komodor, и, boy, was it beautiful. Отличный инструмент, когда нужно быстро собрать логи сервисов и получать summary, что там произошло и почему все сломалось.

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

А какой у вас опыт интеграции такого рода помощников в повседневную работу? Наиболее интересны self hosted решения, потому что слать ваши логи в chatgpt плохая идея)

Помните большой пост про деньги, которые вы сливаете в облако?

В нем я разбирал типичные примеры, озаглавленные общей идеей «Играл с облаками и проиграл». Если пропустили или присоединились к каналу позже — ловите ссылку.

➡️ Классная новость для тех, кто хочет лучше разобраться в вопросе — Слёрм запускает серию бесплатных встреч, на которых будут разбирать решения в области FinOps:

🟠 неверное использование облачных ресурсов из-за непонимания их специфики;
🟠 избыточную надёжность (SRE);
🟠 оverengineering — избыточное усложнение инструментов, пайплайнов, процессов.

➡️ Первый вебинар «Облачные решения: как снизить затраты и повысить эффективность?» — уже на следующей неделе.

Программа вебинара:
➡️ Типичные ошибки при работе с облачными сервисами и их влияние на бизнес.
➡️ Настройка сетевых сервисов и контроль доступа.
➡️ Как неправильный выбор ресурсов может привести к сбоям.
➡️ Почему резервное копирование — обязательная часть стратегии.

Когда: 11 июня в 17:00 мск

Занять место на вебинаре — через бота.

Оптимизация запуска тяжелых образов для ML

Представьте простую задачу.

Есть k8s. Есть ML модели, где веса вшиты в образ приложения. Любая выкатка или переезд контейнера — боль и нагрузка на container registry, потому что не факт, что образ был закеширован на ноде.

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

➡️ Как ускорить процесс запуска многогигабайтных образов?

Конечно, кеш!

Задействуем спящий DaemonSet. Идея простая.

🟠 Создаем DaemonSet с нужным/нужными образами (может быть много разных).
🟠 В качестве команды для этих контейнеров используем, например, sleep infinity.

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

При выкатке приложения:

1. Сначала катим DaemonSet
2. Ожидаем в пайплайне, пока все поды в DaemonSet поднимутся
3. Деплоим приложение

Пример решения, где вместо sleep используется pause container:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prepuller
spec:
  selector:
    matchLabels:
      name: prepuller
  template:
    metadata:
      labels:
        name: prepuller
    spec:
      initContainers:
        - name: prepuller-1
          image: nginx # Наш образ, что подтягиваем в кеш ноды
          command: ["sh", "-c", "'true'"]

        # - name: prepuller-2
        #   image: ...
        #   command: ["sh", "-c", "'true'"]

      containers:
        - name: pause
          image: gcr.io/google_containers/pause:3.2
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
            requests:
              cpu: 1m
              memory: 8Mi

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

Существуют и другие подходы к кешированию, например, такой. Но внутри он все так же создает DaemonSet 😊

Привет! На связи Маркус 🐈

Столько разговоров про этот ваш кубернетес, как будто это что-то вкусное. Хочу разобраться, почему вы все с ним так носитесь, поэтому решил спросить:

➡️ Какой аспект Kubernetes (сети, хранилища, безопасность, RBAC, операторы и т.д.) вы считаете самым недооцененным, но критически важным для стабильной работы?

Поделитесь в комментариях ⬇️

Разгружаем etcd

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

➡️ Давайте просто добавим больше нод! И тут кроется подвох. Дело в том, что etcd работает на основе алгоритма RAFT. И даже чтение данных, не говоря уже о записи, происходит через лидера. Думаю, тут я ни для кого не открыл ничего нового.

Как работает запись в etcd:

🟠 API-сервер отправляет запрос на запись одной из нод etcd.
🟠 Если повезло и запрос попал на лидера, то лидер реплицирует запись на мажоритарное количество нод (например, 2 из 3 или 3 из 5). Только после этого запись считается успешной.
🟠 Если же запрос прилетел на реплику, то он все равно перенаправляется лидеру.
🟠И только после записи на лидере и мажоритарном количестве реплик API-сервер получает подтверждение.

Теперь, зная это, давайте подумаем о масштабировании etcd.

➡️ Представьте себе кластер с 7 нодами etcd. В этом случае запись нужно реплицировать на 4 из 7 нод, что может существенно замедлить процесс (хотя все, конечно, относительно).

Оптимальным считается иметь 3-5 нод etcd. Это обеспечивает достаточную отказоустойчивость и не перегружает репликацию между нодами etcd. Однако, в таком сетапе мы все равно ограничены ресурсами одной ноды.

Но есть решение! Хотя и применять его стоит с большой осторожностью.

Можно вынести хранение events в отдельный кластер etcd (а это, как минимум, еще 3 ноды в ваш кластер). Для этого в конфиге API-сервера нужно указать следующее:

# /etc/kubernetes/manifests/kube-apiserver.yaml
command:
  - kube-apiserver
  - --etcd-servers-overrides=/events#https://etcd-events.example.com:2379
  ...

Разобраться в тонкостях работы etcd можно в гайде от Слёрма ➡️ в боте.

Rancher в продакшен: лучшие практики управления кластерами

Мы с Вячеславом Федосеевым (и Маркусом, конечно же) решили провести совместный веб и поговорить про Rancher. Будем обсуждать:

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

Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, поделимся собственным опытом и best practices.

Когда: 16 июня в 19:00 мск

Занять место на вебинаре ➡️ через бота.

Cloud native практики, которые постоянно нарушаются

Все мы знаем базовые правила.

➡️ Не храните секреты в коде, будь то код приложения или код инфры (terraform, ansible, puppet, etc.).
➡️ Разделяйте prod и dev. Лучше на разные облачные аккаунты, чтобы уменьшить blast radius.
➡️ Руководствуйтесь принципом наименьших привилегий. Да, часто хочется просто накинуть побольше прав очередной IAM роли и не разбираться, а какие права реально нужны.

Но раз за разом эти простые вещи игнорируются в силу разных причин. Ловите чек-лист, на что обратить внимание, чтобы потом не было мучительно больно:

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

➡️ Least privilege: начинать с широких прав доступа кажется удобным, но приводит к огромным проблемам безопасности в будущем.

➡️ Использование IAM ролей (или аналогов)
- Использовать IAM роли для доступа к ресурсам.
- Не использовать статические креды для доступа.
- Использовать короткоживущие ключи доступа.
- Использовать AssumeRole (или аналоги), чтобы позволить, например, EC2 инстансу, временно получить нужные права доступа.

➡️ Регулярная ротация ключей и сертификатов: своевременная ротация ключей доступа и SSL/TLS сертификатов - must have, особенно для прода. Многие подобные ротации в публичных облаках работают из коробки, а где-то нужно дополнительно это настроить.

➡️ Проверка неиспользуемых ролей (пример)

➡️ Включать MFA для всех аккаунтов, особенно для root аккаунта.

➡️ Федеративные аккаунты: должен быть ровно один аккаунт, через который можно управляться всеми остальными (пример)

➡️ Сегментация сети: изоляция различных сред (dev, staging, prod) с помощью VPC и Security Group.

➡️ Шифрование данных: шифрование данных как при хранении (at rest) так и при передаче (in transit). At rest — не опциональный момент и должен быть включен обязательно.

🟠 Infrastructure as code

➡️ Terraform: автоматизация развертывания и управления инфраструктурой. Это позволяет отслеживать изменения, автоматизировать развертывание и избежать ручных ошибок.

➡️ Версионирование IaC: хранить код инфраструктуры в git.

➡️ Автоматизированные пайплайны для развертывания IaC: Интегрировать IaC с CI/CD пайплайнами.

🟠 Мониторинг и логирование

➡️ Централизованное логирование: собирать логи со всех компонентов системы в централизованное хранилище для упрощения анализа и отладки.

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

➡️ Алерты: никто не будет постоянно смотреть в ваши метрики и логи. Без алертов они почти бесполезны для раннего выявления проблем.

🟠 CI/CD

➡️ Автоматизация всего, что возможно: автоматизация развертывания, тестирования, масштабирования и восстановления.

➡️ CI/CD: непрерывная интеграция и непрерывная доставка - основа современной разработки.

➡️ Автоматизированные тесты: писать и запускать тесты (unit, integration, end-to-end) в CI/CD пайплайне.

🟠 Стоимость

➡️ Использовать reserved instances, saving plans или аналоги для сокращения расходов

➡️ Использовать менее отказоустойчивые решения для тестовых сред. Вам не нужно тройное резервирование БД, S3 и так далее практически никогда для dev/staging.

➡️ Автоскейлинг: выключить тестовые среды на ночь — тоже вариант экономии. Увеличивать ресурсы на проде, зная заранее паттерны нагрузки — так же полезно.

➡️ Удаление неиспользуемых ресурсов: регулярно проверять и удалять неиспользуемые ресурсы.

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

➡️ Тегирование ресурсов: правильная система тегов для отслеживания стоимости и принадлежности ресурсов командам.

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