Расскажут инженеры
MWS Cloud Platform ⬜️ в 8-й серии
реалити-проекта для инженеров — Building the Cloud.

📅 Когда: 9 октября в 13:00
📍 Где: Онлайн

Вы узнаете:

⏺️чем реализация ванильного Kubernetes отличается от управляемого сервиса, предоставляемого в облаке;
⏺️какую архитектуру выбрали для managed-решения в облаке MWS Cloud Platform;
⏺️как реализовали жизненный цикл кластеров, мульти-тенанси и интеграции с другими облачными сервисами — Artifact Registry, IAM, Compute, VPC.

🎁 Розыгрыш фирменного мерча — за лучший вопрос в чате.

Будет особенно полезно DevOps- и Cloud Native-инженерам, а также всем, кто интересуется облачными технологиями.

➡️Зарегистрироваться

🚨 570 ГБ данных утекают из GitLab

Группа Crimson Collective заявила о похищении ~570 ГБ данных из внутреннего GitLab-инстанса Red Hat, используемого подразделением консультационных услуг. В числе утечек — отчёты клиентов (CERs), конфигурации и внутренние коммуникации.

В Red Hat подтвердили инцидент, пояснив, что взлом затронул GitLab-инстанс, используемый только в рамках подразделения консультационных услуг, и что инстанс не был публичным сервисом Red Hat.

Ошибки и слабые стороны

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

• По заявлению злоумышленников, они пытались связаться с Red Hat с требованием выкупа, но получили шаблонный ответ и инструкцию подать отчет об уязвимости. Заявляется, что тикет непрерывно переназначался.

• Компания утверждает, что после обнаружения приступила к изоляции и принятию мер. Но вопрос: как быстро был установлен сам факт вторжения? Если задержка была ощутимой — ущерб мог быть намного больше.

Что можно сделать

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

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

• Даже если данные украдены, шифрование может сделать их бессмысленными для злоумышленников.

• Клиенты, чьи данные могли быть скомпрометированы, должны быть уведомлены. Лучше быть честным и открытым.

➡️ Источник

🐸Библиотека devops'a

#разбор_полётов

🤔 Нетривиальный вопрос с собеседования

Сегодня попробуем ответить на такой вопрос:

Что происходит в Kubernetes, когда под не проходит liveness probe

Большинство кандидатов отвечают: «Он перезапускается». Но это — только верхушка айсберга.

Под капотом Kubernetes:

1. Когда liveness probe проваливается kubelet сообщает об этом API Server, который записывает Pod как unhealthy в etcd.

2. Дальше kubelet через containerd/CRI-O убивает контейнер и проверяет restartPolicy:
если можно — перезапускает, если нет — Pod считается завершённым.

3. Контроллер ReplicaSet видит, что живых Pod’ов меньше, и создаёт новый.

4. Scheduler выбирает подходящий узел, а kube-proxy убирает сбойный Pod из маршрутов сервиса.

5. В kubectl describe pod появляются события, но если Prometheus не следит за ними — узнаете о проблеме только от пользователей.

Сеньор-уровень — это не про YAML, а про понимание того, что конкретно происходит.

🐸Библиотека devops'a

#задача_со_звёздочкой

🆕 Материалы недели

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

— Linux 6.17

— Конец эпохи диалап

— Как вайб-кодинг меняет рынок IT-образования

— Вышел релиз-кандидат Argo CD 3.2.0

— Утечка у Red Hat

🐸Библиотека devops'a

#дайджест_недели

✨ Итоги недели

Вспомните самый яркий момент или открытие последних дней. Может, это была неожиданная новость, полезный туториал или просто интересная идея? Расскажите, чем вдохновились или что заставило задуматься.

Ждём вас в комментах 👇

🐸Библиотека devops'a

#голосование_за_контент