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

➡️ 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.

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

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

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

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

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

Что почитать, чтобы отвлечься от ваших кластеров

Подборка для длинных выходных

➡️ Brendan Gregg's Website
Это просто кладезь знаний от человека, который посвятил себя оптимизации Linux. Он не просто рассказывает, что делать, а объясняет, почему и как это работает. Его инструменты — мастхэв для тех, кто хочет копаться в системе на уровне ядра и видеть, где у нее узкие места.

➡️ Systems Performance, 2nd Edition
Это как Библия для системного администратора. Всё, что нужно знать про тюнинг под высокие нагрузки, — от анализа I/O до оптимизации памяти, — тут есть. Книга толстая, но она того стоит, если хотите понимать, как система работает, а не просто тыкать наугад, когда нужно вытянуть перформанс.

➡️ Joel Spolsky's Blog
Особенно обратите внимание на «The Law of Leaky Abstractions». Он объясняет, почему важно понимать, что происходит «под капотом», даже если вы используете самые крутые фреймворки. Он основал Stack Overflow и, наверное, что-то понимает в IT.

➡️ «Awesome Falsehood»
Это просто must-read для любого инженера. Список всех самых распространенных заблуждений, которые только можно себе представить. Почитайте, чтобы не наступать на те же грабли, что и все остальные. На Хабре, кстати, есть переводы на русский – «Заблуждения программистов о времени» и «о картах» — чтобы было понятнее, о чем речь.

➡️ «Wat» Talk
А это чтобы немного расслабиться и понять, что мир неидеален. Знаменитая лекция про странности Ruby и JavaScript. Помогает не воспринимать баги слишком серьезно и вообще немного философски относиться к разработке.

Уроки Google

Вчерашний масштабный сбой в Google Cloud, наряду с инцидентом в Cloudflare, а также недавний пример с падением Yandex Cloud, стали очередным напоминанием о важности диверсификации в построении современных систем.

Нет ничего вечного. Признание того, что всё ломается – первый шаг к построению надежных систем. Главное – как к этому подготовиться?

➡️Пример Cloudflare

Cloudflare - компания, обслуживающая огромную часть интернет-трафика. Парадоксально, но у них нет собственных дата-центров. Вместо этого они арендуют серверы по всему миру. Это позволяет:

🟠Географически распределять нагрузку, что снижает риск одновременного выхода из строя всех серверов.
🟠Быть ближе к пользователю, что улучшает скорость доступа к контенту.
🟠Избегать монополизации, что снижает зависимость от одного поставщика услуг.

Казалось бы, идеальная стратегия диверсификации! Но…

Привет, я Google Cloud и сегодня я упал.

Cloudflare использует Google Cloud для критически важной части своей инфраструктуры. Когда Google Cloud падает, это тянет за собой и Cloudflare, как мы выяснили вчера, а вместе с ним и огромное количество зависимых сервисов, то есть ту самую половину интернета.

➡️Мораль истории

🟠Диверсификация - это хорошо, но она должна быть продуманной. Недостаточно просто распределить ресурсы между разными дата-центрами. Нужно убедиться, что критически важные компоненты не зависят от одного единственного поставщика, даже если это Google Cloud или AWS (у AWS тоже происходят большие сбои).
🟠Необходима возможность не зависеть от одного вендора. Что произойдет, если одна из ваших критичных зависимостей станет недоступна на многие часы или дни? Компании, для которых особенно критична стабильная работа с гарантиями 99.99% надежности, идут в направлении собственных ДЦ и мульти клауд архитектур. И да, это очень дорого.

Если хотите научиться в надежность систем, welcome на курс по SRE. На 3 недели станете SRE для сервиса покупки билетов. Наплыв посетителей, отказ инфраструктуры, сбой платежной системы, а следом еще и DoS-атака. Как восстановить работу сервиса – решать вам.

Атаки на инфраструктуру через забытые ресурсы

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

Относительно легко в такой системе получить «забытые» ресурсы. Настроили что-то с недостаточно жесткими ограничениями, потом оказалось, что нужно делать по-другому, а созданные ресурсы никуда не делись и остались работать. И хорошо, если остались они только во внутренней сети, без возможности достучаться до них снаружи.

А что финансы и оплата всего забытого добра? На фоне общих отчетов какой-нибудь забытый кластер или открытый S3 bucket (классика) будут незаметны в большинстве случаев.

Типовые случаи:

➡️ Неправильно настроенный S3 bucket

🟠 Сценарий

Компания A использовала S3 bucket для хранения бэкапов логов веб-серверов. После миграции на новую систему логирования, старый bucket был забыт. Bucket остался с прежними настройками доступа, включая возможность чтения для аутентифицированных(!) AWS пользователей.

🟠 Атака

Хакер получил доступ к скомпрометированному аккаунту одного из сотрудников компании A. Используя эти credentials, он обнаружил старый S3 bucket и скачал резервные копии логов, содержащие конфиденциальную информацию о пользователях, включая имена, адреса электронной почты и пароли. Да, в логах веб сервера чего только не попадается.

🟠Последствия 

Утечка данных привела к репутационным потерям и штрафам со стороны регуляторов (GDPR).

➡️ Забытый сервисный аккаунт с большими правами

🟠 Сценарий

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

🟠 Атака 

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

🟠 Последствия 

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

➡️ Атака на цепочку поставок через незащищенный container registry

🟠Сценарий 

Компания X использовала устаревшую версию библиотеку в одном из сервисов.  Как потом выяснилось, с известной уязвимостью. Компания не проводила регулярное сканирование образов (почему это важно, и как привести в порядок свои процессы с точки зрения безопасности — на интенсиве Слёрма «DevSecOps Bootcamp»).

🟠 Атака 

Злоумышленник смог проэксплуатировать уязвимость, используй готовые инструкции.

🟠 Последствия 

Через уязвимость получилось выполнить неаутентифицированные запросы во внутренние системы компании, создав множество проблем и вытягивая данные, к которым не должен был иметь доступ. Вспомните уязвимость Log4j (пример).

Уроки

Эти примеры подчеркивают важность проактивного управления ресурсами и регулярного аудита инфраструктуры.

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

Rancher в продакшен: вебинар уже через час

В 19:00 встречаемся на бесплатном вебинаре с Вячеславом Федосеевым, чтобы обсудить:

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

Подробно расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, и почему все продолжают использовать его неправильно.

➡️ Ссылки на трансляцию придут в бота. Подключайтесь!