⚡️ Kubernetes устраняет проблему безопасности с приватными образами, которую не решали более 10 лет

Ранее, при использовании политики imagePullPolicy: IfNotPresent, kubelet мог запускать контейнеры из приватных образов, даже если pod не передавал нужные imagePullSecrets. Это означало, что уже загруженные образы могли использоваться без повторной проверки прав доступа.

Начиная с Kubernetes v1.33, kubelet теперь проверяет учетные данные pod-а даже для локально кэшированных образов. Если образ найден на узле, kubelet удостоверяется, что pod имеет соответствующие pull credentials, прежде чем разрешить его запуск.

Ожидается, что в v1.34 эта функция перейдёт в бета-стадию и получит дополнительные улучшения.

https://kubernetes.io/blog/2025/05/12/kubernetes-v1-33-ensure-secret-pulled-images-alpha/

🧠 DevOps-задача: "Контейнер Шрёдингера"

Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но docker exec показывает, что оно запущено, порт слушает, ошибок нет. Однако при curl изнутри — всё работает, а снаружи — нет ответа."

Что известно:

- Docker-контейнер на основе alpine:3.18
- Приложение запускается через CMD ["/bin/service-start"]
- Порт 8080 проброшен (`-p 8080:8080`)
- curl localhost:8080 внутри контейнера возвращает 200 OK
- curl localhost:8080 на хосте — зависает
- netstat -tulpn показывает, что порт 8080 прослушивается внутри

Задача:
Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ.

📌 Разбор:

🕵️ Подвох №1: **приложение слушает 127.0.0.1:8080**, а не 0.0.0.0
• внутри `curl localhost:8080` работает
• а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host

Решение:
- Проверить снаружи: `docker inspect <container_id> | grep IPAddress`
- Проверить bind-порт внутри:
```bash
netstat -tulpn | grep 8080
# или ss -tulpn | grep 8080
```
- Если видим `127.0.0.1:8080` — всё ясно: нужно слушать на `0.0.0.0:8080`

🛠 Исправление:

1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3 app.py
```
и он слушает только на localhost? Добавь:
```bash
python3 app.py --host=0.0.0.0
```

2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на 127.0.0.1
Проверь в настройках приложения или командной строке

🎯 Что проверяет задача:

• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера

Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.

🦙 RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо.

Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.

🤖 GitHub

@devopsitsec

🌐 Задача-ловушка: Пропавший трафик после настройки iptables

Условие:

На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.

На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:

docker run -d -p 8080:80 nginx

❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает.

Дополнительно, если выполнить:

curl http://localhost:8080

— сервер отвечает нормально. Но с других машин — нет.

❓ Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?

🔍 Подсказка:

Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов.


✅ Разбор:

💥 Ловушка:

Ваш iptables-правила:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так!

Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:

- Входящий пакет попадает в цепочку PREROUTING (nat)
- Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера

И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:

iptables -P FORWARD DROP

Поэтому трафик до контейнера блокируется именно на этапе FORWARD.

🔧 Как проверить:

Запустить:

iptables -L -v -n

Вы увидите, что счётчик пакетов в FORWARD показывает дропы.

🛠 Как починить:

Добавить правило разрешения проброса пакетов для Docker:

iptables -A FORWARD -o docker0 -j ACCEPT

Или (более строго):

iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT

✅ Вывод:

• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)

• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT.

💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?

🛠️ Отправка уведомлений Slack из shell-скриптов

Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях.

Сервер упал? Получите уведомление.
Скрипт завершил выполнение? Получите уведомление.

Добавив уведомления Slack в свои shell-скрипты, вы можете:
- 📣 легко делиться результатами работы скриптов с командой,
- 🛡️ быстро реагировать на проблемы,
- 🔍 быть в курсе событий без просмотра логов.

> Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash.

🔗 Webhook + curl: секретная связка

Slack позволяет использовать входящие Webhook-и для получения сообщений.
А curl позволяет отправлять эти сообщения через HTTP POST.

Принцип:
- Slack даёт вам URL вида https://hooks.slack.com/services/...
- Вы используете curl для отправки JSON с текстом сообщения.

⚙️ Как включить входящие Webhook в Slack

1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps)
2. Создайте новое приложение
3. В разделе Incoming Webhooks — активируйте их
4. Добавьте Webhook в рабочее пространство (выберите канал)
5. Сохраните Webhook URL — он понадобится далее

💬 Bash-скрипт для отправки уведомлений

Добавьте Webhook в .bashrc:

export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/your/webhook/url"

Пример скрипта мониторинга:

#!/bin/bash

source ~/notify_slack.sh

disk_usage=$(df -h / | awk 'NR==2 {print $5}')
cpu_load=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d',' -f1 | xargs)
hostname=$(hostname)

message="*Отчёт о системе - $hostname*\n* Диск (/): $disk_usage\n* CPU (1 мин): $cpu_load"
notify_slack "$message"

✅ Рекомендации

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

Slack ограничивает частоту Webhook-запросов

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

Теперь вы можете:

- Добавить Slack-уведомления в свои cron-задачи

- Отслеживать состояние системы

- Получать оповещения об ошибках в скриптах.

Подробнее

🚀 VS Code трансформируется в опенсорнсый ИИ-редактор!

Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ.

Конкуренция - двигатели прогресса! Где-то напряглась команда Cursor 🤓

🔗 Подробности: aka.ms/open-source-ai-editor

#VSCode #OpenSource #ИИ #Разработка #Сообщество

🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google

Контейнер — это не просто Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров:

⚫ Ограничь права контейнера

docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...

▪️ --read-only — защищает файловую систему
▪️ --cap-drop=ALL — удаляет лишние привилегии
▪️ no-new-privileges — запрещает повышение прав в процессе

⚫ Установи лимиты CPU и памяти

docker run --memory="512m" --cpus="1.5" ...

▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах
▪️ Используй cpu-shares, cpuset, ulimits для тонкой настройки

⚫ Чисти от мусора
- Используй multi-stage builds — минимизируй размер образа
- Оставляй только необходимые бинарники и конфиги
- Пример:

FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]

⚫ Используй distroless или Alpine
- Образы типа gcr.io/distroless/static — без шелла, package manager и мусора
- alpine — легче, но следи за совместимостью с glibc

⚫ Пропиши healthcheck

HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1

▪️ Kubernetes будет перезапускать только при реальных сбоях

⚫ Подключи observability
- Встраивай Prometheus exporter
- Логи — в stdout/stderr (для kubectl logs и EFK/PLG стека)
- Используй otel, если нужен tracing

⚫ Проверь, чем занят контейнер

docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>

▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через /dev

💡 Эти практики критичны, если:
- Вы деплоите в прод с autoscaling
- Контейнеры крутятся в k8s или Fargate
- Вам важно сократить издержки на ресурсы и повысить безопасность

Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.

@devopsitsec

⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу.

Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.

🤖 GitHub

@devopsitsec

🏰 SSHportal — умный шлюз для SSH-доступа без головной боли. Этот проект превращает управление SSH-доступом в интуитивный процесс. Вместо ручного редактирования authorized_keys на каждом сервере, SSHportal централизует контроль через единую точку входа с ролевой моделью доступа.

Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами.

🤖 GitHub

@devopsitsec

🧠 Claude Opus решил баг, с которым я боролся почти 5 лет — личная история разработчика C++ и бывшего старший инженер FAANG с

💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus.
Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова.

🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ.

📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления.

🔍 Что можно вынести:
• Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть
• Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение
• Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке

📎 Оригинальный пост на Reddit

@devopsitsec

🌒 LunaTrace — бесплатный open-source инструмент для аудита безопасности зависимостей. Он автоматически сканирует зависимости в проектах, выявляет уязвимости и интегрируется с GitHub Pull Requests, чтобы предупреждать о рисках до деплоя.

Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем.

🤖 GitHub

@devsecops

🔍 Google Cloud представил **KHI (Kubernetes History Inspector)** — инструмент, который превращает логи Kubernetes в интерактивную визуальную историю.

🧠 Зачем нужен KHI:
• Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад
• KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами

🚀 Что умеет:
• Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения
• Поддерживает фильтры и поиск — быстро находит нужные события
• Работает без агентов — использует уже существующие логи
• Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое

🛠 Подходит для:
• Отладки инцидентов и RCA (root cause analysis)
• Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда

📎 GitHub: https://github.com/GoogleCloudPlatform/khi


@devopsitsec

⚡️ Composerize — мгновенное преобразование docker run в docker-compose. Composerize решает проблему нечитаемых строк с десятками флагов одним движением — конвертирует запуск контейнера через CLI в аккуратный compose.yaml.

Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.

🤖 GitHub

@DevopsDocker

🗄 YTsaurus теперь как сервис в Yandex Cloud

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

Поддерживает работу с эксабайтами, масштабируется до миллиона CPU, работает с ClickHouse, Spark, MapReduce. Можно строить пайплайны, гонять аналитику, собирать хранилища и обрабатывать логи - всё в одной системе.

Стриминговые, структурированные и неструктурированные данные - поддержка на уровне ядра. Подходит как для тяжёлых ML-задач, так и для типовых ETL-процессов.
Инфраструктура управляется как сервис - без ручного развертывания и поддержки.

@devopsitsec

☸ История создания Kubernetes — от внутреннего инструмента Google до мировой революции
Когда в 2014 году Google выложил в открытый доступ свой внутренний проект под странным именем Kubernetes, мало кто осознал, что это начало настоящей контейнерной революции. Но за этой лаконичной оболочкой скрывалась мощь, проверенная на миллиардах пользователей Google Search, Gmail и YouTube.

🔥 Всё началось с Borg
Внутри Google уже с 2003 года существовала система управления контейнерами — Borg. Это был секретный, монструозный и невероятно мощный оркестратор, позволявший запускать сотни тысяч задач на десятках тысяч серверов. Но Borg был закрыт, сложный и не предназначен для внешнего мира.

💡 Факт: Borg умел автоматически лечить упавшие сервисы задолго до того, как "self-healing" стал модным словом в DevOps.

🚀 Почему Kubernetes?
Google хотел подарить миру упрощённую, но эффективную версию Borg — с понятным API, без проприетарных завязок и... с хорошим маркетингом. Так родился Kubernetes — проект с открытым исходным кодом, построенный на Go, и вдохновлённый Borg и его экспериментальным "младшим братом" — Omega.

🔷 Факт: Название "Kubernetes" пришло из греческого языка и означает "штурман". Это намёк: Kubernetes управляет "флотом" контейнеров как кораблями.

👨‍💻 Кто стоял у истоков?
Изначально за Kubernetes отвечали три инженера Google:

Joe Beda

Brendan Burns

Craig McLuckie

Позже к ним присоединился Brian Grant, архитектор Borg, и вскоре десятки инженеров со всего мира стали развивать проект под крылом Cloud Native Computing Foundation (CNCF).

🧨 Факт: Kubernetes стал самым активным проектом на GitHub в 2015 году — больше коммитов, чем у Linux!

🌐 Как Kubernetes завоевал мир?
🔄 Контейнеры стали стандартом благодаря Docker, но их нужно было как-то управлять — и тут вошёл Kubernetes.

🎯 Kubernetes оказался универсальным: он мог запускаться на ноутбуке, в дата-центре, в облаке, даже на Raspberry Pi.

💥 Все большие игроки — AWS, Azure, IBM, Red Hat — вынуждены были поддержать Kubernetes, иначе рисковали остаться вне игры.

📦 Экосистема вокруг Kubernetes выросла в десятки раз: Helm, Istio, Prometheus, ArgoCD, Knative — всё это родилось в его тени.

🛡 Факт: Kubernetes — это не просто оркестратор. Это операционная система для облака. Она изменила сам подход к разработке: теперь приложения проектируются "cloud-native", а не "серверные".

⚙️ Kubernetes сегодня
Сейчас Kubernetes:

Работает в каждом втором крупном enterprise-проекте

Поддерживается всеми облачными провайдерами

Является де-факто стандартом для микросервисной архитектуры

Вдохновил создание K8s-альтернатив: Nomad, OpenShift, K3s, и других

💡 Вывод
Kubernetes — это не просто проект, это движение, начатое с утечки идей из недр Google и переросшее в открытую революцию управления инфраструктурой. Как Git изменил подход к коду, так Kubernetes изменил подход к запуску программ. Сегодня без Kubernetes — ни один серьёзный DevOps не чувствует себя в безопасности.

Хочешь больше таких историй из мира технологий? 😉

https://www.youtube.com/shorts/CNVdG6LS9kE

🌟 Selenium Docker Images — готовые контейнеры для автотестов
Для тех, кто устал настраивать Selenium Grid вручную, сообщество Selenium выкатило официальные Docker-образы. В одном контейнере уже собраны браузеры (Chrome, Firefox, Edge), VNC для отладки и сам Selenium Server — остаётся только запустить тесты.

Инструмент особенно удобен для CI/CD:
— Поддержка multi-arch (amd64, arm64)
— Готовые теги для beta-версий браузеров
— Встроенная запись видео тестов

Запуск элементарный:

docker run -d -p 4444:4444 --shm-size=2g selenium/standalone-chrome

🤖 GitHub

@DevopsDocker

🚀 go-svelte-spa — простой шаблон для Go + Svelte SPA

🔗 https://github.com/joelseq/go-svelte-spa

Этот проект — минималистичный стартовый шаблон, который объединяет мощь Go и фронтенд на Svelte в одном репозитории. Отлично подойдёт для быстрого создания одностраничных приложений (SPA) с современным интерфейсом и надёжным сервером.

🧩 Что внутри:

✅ Go-сервер:
- Отдаёт статические файлы фронтенда
- Поддерживает SPA-маршруты через fallback на index.html

✅ Svelte SPA:
- Структура с App.svelte, маршрутизацией и Vite
- Лёгкий, быстрый и понятный фронтенд

✅ Makefile + Vite + Docker (опционально)

⚙️ Как запустить:

# Сборка фронта
cd frontend
npm install
npm run build

# Запуск Go-сервера
cd ..
go run main.go

📦 Кому подойдёт:
- Go-разработчикам, которым нужен современный UI
- Тем, кто хочет обойтись без сложных фреймворков
- Для MVP, pet-проектов, админок и внутренних тулов

🔥 Если хочешь быстрый и удобный стек без лишнего — go-svelte-spa отличный выбор.

📁 Репозиторий: https://github.com/joelseq/go-svelte-spa

🛠 25+ FTP-вопросов для собеседований: разбор с ответами

Если ты DevOps-инженер, системный администратор или сетевой специалист, то протокол FTP (File Transfer Protocol) тебе наверняка знаком. На собеседованиях часто задают вопросы по его устройству, безопасности и конфигурации. Команда Tecmint собрала ключевые FTP-вопросы с ответами, которые стоит выучить. Вот основные из них:

🔹 Что такое FTP?
File Transfer Protocol — это стандартный сетевой протокол, используемый для передачи файлов между клиентом и сервером по TCP/IP.

🔹 На каких портах работает FTP?
По умолчанию:
• Порт 21 — управляющее соединение
• Порт 20 — передача данных (в активном режиме)

🔹 Чем отличается активный и пассивный режим FTP?
В активном режиме сервер инициирует соединение для передачи данных, в пассивном — клиент сам подключается к случайному порту сервера.
💡 Пассивный режим чаще используют за NAT/фаерволами.

🔹 Что такое анонимный FTP?
Это доступ к FTP-серверу без пароля (обычно используется anonymous или ftp в качестве логина). Часто применяется для публичных загрузок.

🔹 Какие популярные FTP-серверы в Linux?
• vsftpd
• proftpd
• Pure-FTPd

🔹 Как обеспечить безопасность FTP?
Обычный FTP передаёт данные в незашифрованном виде. Для защиты используют:
• FTPS (FTP over SSL/TLS)
• SFTP (через SSH) — это вообще другой протокол
Также: ограничение по IP, chroot jail, шифрование паролей, запрет анонимного доступа.

🔹 Различия между FTP и SFTP?
• SFTP работает через SSH (порт 22)
• Обеспечивает полное шифрование
• Безопаснее, но несовместим с обычными FTP-клиентами

🔹 Какие команды FTP стоит знать?
• get, put — загрузка и выгрузка
• ls, cd, pwd, mget, mput
• passive / active — переключение режима

🔹 Как ограничить пользователя FTP в своём каталоге?
Через chroot jail: chroot_local_user=YES в vsftpd.conf

🔹 Как протестировать FTP-сервер?
Можно использовать:
• ftp (CLI)
• lftp — продвинутый CLI
• GUI-клиенты: FileZilla, WinSCP

📚 Все 25+ вопросов с ответами ты найдёшь тут → https://www.tecmint.com/ftp-interview-questions-and-answers/

⚙️ Отличный чеклист для подготовки к собеседованию или аудиту инфраструктуры!

#FTP #DevOps #Linux #Собеседование #Sysadmin #SFTP #Безопасность


@devopsitsec