🧑‍💻 Ошибка неуязвимого

Kubernetes по умолчанию не строгий. Можно запустить контейнер от root, использовать image:latest, дать всем cluster-admin. Кластер работает — зачем что-то менять?

Что происходит

Контейнер от root может сбежать на ноду через уязвимость. Тег :latest означает, что в prod может задеплоиться любая версия — вчера работало, сегодня нет. Роль cluster-admin даёт права удалить весь кластер.

Как исправить

Настройте RBAC. Создайте роли с минимальными правами:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Добавьте Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted

Теперь в namespace нельзя запустить контейнер от root, с privileged, без securityContext.

Если нужна более гибкая политика — Kyverno или OPA Gatekeeper. Напишете правило один раз — оно будет работать для всех подов.

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

#арсенал_инженера

🔄 Обновления недели

Неделя была богата на релизы, вспомним её богатства:

— Consul 1.22

— Wine 10.18

— Grafana Mimir 3.0

— Devuan 6 Excalibur

— LXQt 2.3.0

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

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

👨‍💻 Как добить поды, если они зависли

Вы удалили ReplicationController с дюжиной подов. Большинство исчезли. Но несколько упрямцев остались висеть в состоянии Terminating, игнорируя ваши попытки удаления.

Когда Kubernetes удаляет под, kubelet выполняет аккуратное завершение: отправляет SIGTERM, ждёт до истечения terminationGracePeriodSeconds, останавливает контейнеры, размонтирует тома и сетевые пространства имён. Финальный шаг — удаление пода с ноды и из API.

Но если размонтирование не удаётся из-за ошибки "device or resource busy", процесс завершения зависает. API-объект остаётся в лимбо состояния Terminating навсегда.

Корень проблемы обычно один: рантайм контейнера оставил утечку — смонтированный том или процесс, который по-прежнему держит файловые дескрипторы.

Быстрая диагностика

Посмотреть есть ли на поде финализаторы:

kubectl get pod <POD> -o jsonpath='{.metadata.finalizers}'

Если они есть — не рубите их сплеча. Это обычно finalizer-ы хранилища (PVC, CSI), которые блокируют удаление до завершения очистки.

Нет финализаторов? Тогда ищем утечку монтирования на уровне хоста.

Подключитесь к ноде, где запускался под:

POD=pod-186o2
NS=default
UID=$(kubectl get pod $POD -n $NS -o jsonpath='{.metadata.uid}')

# На ноде смотрим, что смонтировано
grep -F "$UID" /proc/mounts || true
findmnt | grep "$UID" || true

Если видите записи типа /var/lib/kubelet/pods/<UID>/volumes/... — это ваш виновник.

Теперь узнаем, кто держит монтирование:

lsof +D /var/lib/kubelet/pods/$UID 2>/dev/null | head

Чистим руками

Для Docker:

docker ps --no-trunc | grep $POD
docker stop <containerID>
# Если совсем ничего не помогает (лаха!):
systemctl restart docker

Для containerd:

crictl ps | grep $POD
crictl stopp <containerID>
crictl rmp <containerID>
# Последняя линия защиты:
systemctl restart containerd

Если контейнер мёртв, но монтирование остаётся:

umount -l /var/lib/kubelet/pods/$UID/volumes/<driver>/<vol> || true

Теперь, когда освободили держание:

kubectl delete pod $POD -n $NS

Если всё ещё не уходит:

kubectl delete pod $POD -n $NS --grace-period=0 --force

Это API-уровневый молот. Безопасен для очистки зависшей записи, но используйте только после того, как разобрались с утечками на ноде. С особой осторожностью для StatefulSet.

Видите Terminating, который не уходит? Не спешите с --force. В девяти случаях из десяти kubelet вам что-то говорит: что-то остаётся смонтированным или используется.

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

#арсенал_инженера

🔄 Обновление firewalld

Вышел релиз firewalld версии 2.4.0 — динамически управляемого межсетевого экрана для Linux.

Основные новшества:

• Добавлен набор правил gateway, обеспечивающий функциональность типового домашнего маршрутизатора: NAT, обработка conntrack и перенаправление трафика между зонами.

• Введён флаг disable, который можно применять в XML-конфигурациях, через командную строку и D-Bus для отключения отдельных правил и наборов правил.

• Максимальная длина имён правил увеличена с 17 до 128 символов.

➡️ Release notes

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

#пульс_индустрии

▶️ Запуск CI из Jira

Часто нужно запустить специфичную джобу для конкретной задачи: пересчитать метрики, перепроверить безопасность, прогнать дополнительные тесты. Обычно мы идём в Jenkins или GitHub Actions, ищем нужную джобу, вводим параметры.

Информация о нужном действии находится в Jira, но инструмент для его выполнения — отдельно. Хочется проще: добавил лейбл к задаче и всё запустилось автоматически.

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

Jira отправляет вебхук с информацией о лейблах в GitHub через repository_dispatch. GitHub Actions ловит это событие, парсит лейблы и запускает нужные шаги. На примере ниже: если в Jira добавили лейбл rebuild-docker, GitHub Actions пересобирает Docker образ. После выполнения можно написать результат комментарием обратно в Jira.

name: Jira Triggered Job

on:
  repository_dispatch:
    types: [jira-trigger]

jobs:
  handle-trigger:
    runs-on: ubuntu-latest
    steps:
      # Парсим labels из payload'a
      - name: Parse Jira event
        id: parse
        run: |
          LABELS="${{ fromJSON(github.event.client_payload).labels }}"
          ISSUE="${{ fromJSON(github.event.client_payload).issueKey }}"
          
          echo "issue=$ISSUE" >> $GITHUB_OUTPUT
          echo "labels=$LABELS" >> $GITHUB_OUTPUT
          echo "Получены labels: $LABELS для issue: $ISSUE"
      
      # Если в labels есть 'rebuild-docker', запускаем пересборку
      - name: Rebuild Docker
        if: contains(steps.parse.outputs.labels, 'rebuild-docker')
        run: |
          echo "🐳 Пересобираем Docker для ${{ steps.parse.outputs.issue }}"
          docker build -t myapp:latest .
          docker push myapp:latest
          echo "DOCKER_STATUS=✅ Docker образ успешно пересобран" >> $GITHUB_ENV
      
      # Если в labels есть 'run-tests', запускаем тесты
      - name: Run Tests
        if: contains(steps.parse.outputs.labels, 'run-tests')
        run: |
          echo "✅ Запускаем тесты для ${{ steps.parse.outputs.issue }}"
          npm test
          echo "TESTS_STATUS=✅ Тесты пройдены успешно" >> $GITHUB_ENV
      
      # Если в labels есть 'security-scan', запускаем проверку безопасности
      - name: Security Scan
        if: contains(steps.parse.outputs.labels, 'security-scan')
        run: |
          echo "🔒 Security scan для ${{ steps.parse.outputs.issue }}"
          npm audit
          echo "SECURITY_STATUS=✅ Security scan завершен" >> $GITHUB_ENV
      
      # Пишем результаты комментарием в Jira
      - name: Comment in Jira
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const issue = context.payload.client_payload.issueKey;
            const labels = context.payload.client_payload.labels;
            
            let comment = '🤖 Автоматизированные действия:\n\n';
            
            if (labels.includes('rebuild-docker')) {
              comment += '✅ rebuild-docker: Docker образ пересобран\n';
            }
            if (labels.includes('run-tests')) {
              comment += '✅ run-tests: Тесты запущены\n';
            }
            if (labels.includes('security-scan')) {
              comment += '✅ security-scan: Проверка безопасности завершена\n';
            }

Затем добавьте триггер в Jira, который будет отправлять пейлод:

{
  "event_type": "jira-trigger",
  "client_payload": {
    "issueKey": "{{issue.key}}",
    "labels": "{{issue.labels}}"
  }
}

на урл:

https://api.github.com/repos/ВАШ_НИК/ВАШ_РЕПО/dispatches

с headers:

Authorization: token ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Accept: application/vnd.github.v3+raw+json
Content-Type: application/json

Замените ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx на ваш GitHub токен, который можно получить по пути GitHub → Settings → Developer settings → Personal access tokens → Tokens.

Это особенно полезно в больших командах, где не все имеют доступ к GitHub Actions, но все работают с Jira. QA может добавить security-scan — и проверка запустится автоматически.

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

#арсенал_инженера

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

#пятничный_деплой

💾 На полке в университете нашли Unix

В хранилище Университета Юты нашли магнитную ленту 1973 года с надписью «UNIX Original From Bell Labs V4». Если это действительно четвёртая версия Unix, то это один из самых важных артефактов в истории программирования.

V4 — это первая версия Unix, написанная на языке C вместо ассемблера. Именно это сделало Unix портируемым: код можно было скомпилировать для разных компьютеров почти без изменений.

Полная копия V4 долго считалась потеряной. Остались только куски кода и справочные страницы. Третья и пятая версии хорошо документированы, а четвёртая — пропуск в истории. Между тем она знаменует момент, когда операционная система превратилась из эксперимента Bell Labs в систему, которую можно переносить и учиться на ней.

➡️ Источник

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

#пульс_индустрии

🛠 Изоляция тестовых данных

Изоляция тестов — критичный момент в стабильном тестировании с базами данных. Проблемы возникают когда тесты используют общие ресурсы или порядок запуска влияет на результат из-за утечки состояния.

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

export TEST_SCHEMA="t_$(uuidgen | tr -d '-')"
psql -c "CREATE SCHEMA ${TEST_SCHEMA};"
pytest --db-schema="${TEST_SCHEMA}" ; rc=$?
psql -c "DROP SCHEMA ${TEST_SCHEMA} CASCADE;"
exit $rc

Схема создаётся перед тестами, используется, например, в pytest через параметр --db-schema, а затем удаляется.

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

#root@prompt

🤩 MX Linux наконец стал systemd-friendly

Вышла MX Linux 25 «Infinity» — первая версия, построенная на Debian 13 «Trixie».

Главное изменение: если раньше MX позиционировал себя как systemd-free дистрибутив, то теперь все ISO идут с systemd по умолчанию. Это не значит, что сторонников sysVinit выгнали — для Xfce и Fluxbox есть sysVinit варианты.

Инсталлятор получил поддержку 64-bit UEFI Secure Boot. Теперь можно ещё и настроить zram swap-устройства. Доступны три десктопа: Xfce 4.20, KDE Plasma 6.3.6 и Fluxbox 1.3.

➡️ Release notes

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

#пульс_индустрии

🔒 Статистика паролей за 2025 год

В 2025 году наибольший слив паролей случился с утечкой 16 миллиардов паролей — одна из крупнейших в истории. При этом 94% пользователей повторяют пароли на разных сервисах, что усиливает риски.

Три четверти паролей не соответствуют базовым требованиям безопасности, а простые пароли типа «123456» до сих пор в лидерах по использованию.

💬 Какие практики применяются у вас на проекте? Находили листочки с паролями на мониторе? Делитесь в комментах👇

➡️ Статистика по паролям

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

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

❓ Как внедрить zero-trust между микросервисами

Для внедрения zero-trust между микросервисами в DevOps нужно последовательно наложить несколько ключевых слоёв безопасности.

Первое — включить mTLS с распределённой идентичностью на уровне ворклоадов с помощью SPIFFE/SPIRE. Это значит каждой службе присваивается короткоживущий X.509-сертификат (SVID), который автоматически ротацируется и используется для взаимной аутентификации и шифрования трафика.

Такой подход исключает хранение статичных сертификатов и полностью автоматизирует управление ими.

Далее — построить авторизацию по идентичности, используя RBAC или Open Policy Agent (OPA). Это даёт возможность задавать политики доступа в зависимости от конкретной сущности-сервиса, а не на уровне IP или сети. Ещё слой сетевых ограничений добавляют Kubernetes NetworkPolicy, которые ограничивают коммуникацию только разрешёнными путями.

В Kubernetes для реализации zero-trust-mTLS удобно использовать сервис-меши типа Istio, Linkerd или Ambient Mesh (sidecarless). Для мультикластера нужна федерация trust domains, чтобы распространять доверие и идентификацию между кластерами, а также централизованный аудит для мониторинга и инцидент-реакции.

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

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

😊 AI-помощник, который всегда под рукой

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

Вы просто кликаете «Watch Screen», и помощник анализирует ваш экран, помогая разобраться с любыми вопросами без излишних переключений. Это экономит время и позволяет сохранить концентрацию на важном.

➡️ Поспрашивать про свой экран

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

#арсенал_инженера

📉 Главные тренды DevOps в России

Новый отчет State of DevOps Россия 2025 раскрывает ключевые направления развития практики DevOps в России.

Cloud-трансформация — отдельный важный тренд. Managed- и PaaS-сервисы меняют подходы к инфраструктуре и автоматизации процессов.

DevSecOps в отчете рассматривается как необходимый элемент безопасности, внедряемый без ущерба для скорости разработки.

Искусственный интеллект становится помощником, снимая нагрузку с специалистов и оптимизируя бизнес- и продуктовые процессы.

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

#пульс_индустрии

🛠 Управление политикам в Kubernetes по-человечески

Kyverno — это policy engine, работающий внутри Kubernetes. Он позволяет проверять, изменять и создавать ресурсы на основе заданных политик.

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

Kyverno поддерживает проверку подписей образов, что помогает контролировать цепочку поставок и предотвращать запуск неподписанных или скомпрометированных образов.

В недавнем обновлении 1.16.0 появились новые фичи и фиксы:

• Добавлен vigilant mode, который запрещает использование celPreconditions без validate.cel.

• Исправлены ошибки в тестах generate VAP chainsaw.

• Добавлены функции генерации отчетов для MAPs.

• Исправлены проблемы с обновлением статуса, вызванные разным форматом времени.

• В Helm chart добавлена поддержка рендера Openreports ресурсов и возможность включения соответствующих флагов.

И другие изменения.

➡️ Репозиторий
➡️ Release Notes

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

#арсенал_инженера

📎 Что такое systemd и зачем он нужен в Linux

systemd — это система инициализации и менеджер сервисов, которая отвечает за запуск, остановку и управление процессами в Linux. Он запускается первым после загрузки ядра и держит под контролем все службы и задачи, которые нужны системе и приложениям.

До появления systemd в Linux популярны были разные init-системы, например, SysVinit. Они работали по очереди и запускали сервисы последовательно. Это приводило к долгой загрузке и сложностям с управлением зависимостями.

systemd изменил подход — он запускает сервисы параллельно и учитывает зависимости. Его модульная архитектура позволяет расширять функциональность, а удобные команды systemctl и journalctl сделали администрирование проще и понятнее.

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

Кроме инициализации systemd управляет сервисами через понятные unit-файлы — они описывают, как запускать и перезапускать службы, какие ресурсы выделять и как реагировать на ошибки. Пример простого юнита службы:

[Unit]
Description=Пример сервиса

[Service]
ExecStart=/usr/bin/your-app
Restart=always

[Install]
WantedBy=multi-user.target

systemd стал де-факто стандартом для большинства дистрибутивов Linux благодаря своей функциональности и удобству. Он избавляет от множества рутинных операций и упрощает управление системой.

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

#арсенал_инженера

👀 Что действительно скрывают обещания гибкого графика и карьерного роста в IT

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

Обещания карьерного роста обычно подразумевают, что сами будете решать все проблемы в условиях авралов и большого объёма работы.

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

➡️ Узнать, что работодатели имеют в виду

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