Меняем смонтированный с RO файл без остановки контейнера

На хосте запущен consul через docker run с монтированием цепочки сертификатов
--volume /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro


Когда на хосте утилита обновления сертификатов update-ca-certificates отработала, она удалила старый файл ca-certificates.crt и создала новый.
Но внутри контейнера старый файл был примонтирован. В терминологии ядра Linux этот bind-mount превратился в призрак (unlinked inode).

Нам нужно сначала "отмонтировать" этот мертвый файл-призрак. И вот поверх него мы сможем успешно смонтировать новый сертификат.

# получить первый PID контейнера на хосте
PID=$(docker inspect -f '{{.State.Pid}}' consul)

# Скопировать файл в контейнер
docker cp /etc/ssl/certs/ca-certificates.crt consul:/tmp/new-ca.crt

# Отмонтировать старый inode (удаленный файл) из namespace контейнера
nsenter -t $PID -m -r umount -l /etc/ssl/certs/ca-certificates.crt

# Примонтировать 
nsenter -t $PID -m -r mount --bind -o ro /tmp/new-ca.crt /etc/ssl/certs/ca-certificates.crt

Дальше можно перечитать конфиг consul.
это все равно не помогло, пришлось рестартить consul😐

О, днс, как много мы о тебе не знаем

Интересное обсуждение сегодня было в одном чатике, вынесу сюда факты.

ТС спросил о странном поведении при резолве сайта api.themoviedb.org - некоторые dns сервера возвращают 127.0.0.1. Что интересно, такое поведение при одних и тех же запросах у разных людей может отдавать как искомые адреса, так и локалхост

$ dig +dnssec api.themoviedb.org @1.1.1.1
ответ: 127.0.0.1 | а может быть 18.66.233.*

$ dig +dnssec api.themoviedb.org @8.8.8.8
ответ: 127.0.0.1

$ dig +dnssec api.themoviedb.org @9.9.9.9
ответ: 108.157.229.* или 18.66.233.*

В отличие от других DNS, Quad9 не использует EDNS-Client-Subnet (ECS) для передачи IP-адреса пользователя в DNS-запросах, что защищает геолокацию от отслеживания сайтами.

спросим у восьмёрок ещё раз:

$ dig +dnssec +subnet=8.8.8.8/24 api.themoviedb.org @8.8.8.8
Возвращает не локалхост.

UPD:

В AWS Route53 есть возможность настроить геофенсинг, и в зависимости от страны, откуда пришел запрос, отдавать разные ответы, все эти ответы будут подписаны теми же самыми dnssec ключами. Но весь этот детект идет как раз на базе EDNS0
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html

И тут есть один важный момент:

When a browser or other viewer uses a DNS resolver that does not support edns-client-subnet, Route 53 uses the source IP address of the DNS resolver to approximate the location of the user

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

ну и как же не перепостить про себя любимого) В общем да, коллабимся с лучшими, пилим крутой курс

https://www.opennet.ru/opennews/art.shtml?num=64984
под вечер пятницы 13-е =)

вот как надо вакансии рекламировать, а не вот этот вот всё - плюшки-дмсы-прочее. само разлетится =)
если это был преднамеренный ход - отличная идея

Крупнейший взлом Trivy, продолжение

Прошлый раз были, оказывается, лишь цветочки.

https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise

В результате новой атаки были подменены 75 из 76 тэгов версий Trivy. Все, кто использовал версию кроме 0.35.0 (или просто все, начиная от 0.18.0 с промежуточными), получили вредоносный коммит, который крадёт:

- AWS/GCP/Azure креды
- SSH-ключи
- git-credentials
- Kubernetes service account tokens и секреты
- GitHub Secret, переданные в GitHub Runner
- Крипто-кошельки

Пострадали более 10000 GitHub workflow-файлов, которые используют trivy-action по тегу версии.

Что делать прямо сейчас

Если у вас есть исполнения с:

uses: aquasecurity/trivy-action@<любая версия кроме 0.35.0>

считайте, что ваши данные уже записаны "где не надо".

Безопасные варианты только два:
- Тег @0.35.0
- Пин по SHA: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

Как признак проблем - проверить в GitHub логах запросы к репозиторию tpcp-docs, который использовался в такой схеме врагами.

Лучи поддержки команде Trivy. Всем, кто использовал trivy-action в последнее время — перепроверить и в любом случае лучше обновить секреты.

1.0 release of Ingress2Gateway

Ingress в Kubernetes постепенно уходит: ingress-nginx официально перестанут поддерживать с марта 2026.
Под это как раз вышел Ingress2Gateway 1.0 — инструмент, который конвертирует существующие Ingress-манифесты в новый формат Gateway API (Gateway, HTTPRoute и т.д.). То есть можно взять уже работающие ingress’ы и не переписывать всё руками.

Сам Gateway API — более гибкая и чистая модель (меньше магии с аннотациями, больше нативных возможностей). А Ingress2Gateway упрощает переход: вместо ручной миграции — автоматическая конверсия и постепенный переход.

https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/?utm_source=tg&utm_medium=devops&utm_campaign=240326

(written by this guy: Chatham Gptman)

Сисадмин, хочешь делать +30к в месяц?

Партнерская программа Яндекс Браузера позволяет зарабатывать дополнительные деньги за то, что вы по факту и так делаете на работе.
За каждого пользователя, которому вы установите приложения Яндекса, программа дает до 600 рублей — можно спокойно зарабатывать дополнительно 30к в месяц и даже больше.

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

👉Узнать подробные условия и начать зарабатывать

Технологический радар и принятие изменений

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

В иллюстрации пример выбора замены minio - как вы знаете с недавнего времени они стали полностью коммерческим продуктом, уйдя из поля open source.

А как у вас происходит выбор применяемых технологий? и кто уже что для себя решил чем заменить minio?

з.ы. телеграм жутко пережал картинку, выкладываю файлом

Кубер. Поды. Это основа.
И это только начало.

Kubernetes from Zero to Hero — видеокурс, который проведёт вас от первого знакомства с Kubernetes до Helm, Ingress и ConfigMap.

10 выпусков на YouTube, всё по порядку:
1 — Ты точно знаешь, что такое Kubernetes?
2 — Как запустить Kubernetes локально: пошаговая инструкция с Minikube
3 — Pod и Deployment в Kubernetes — это база, это знать надо
4 — Как собрать Docker-образ с werf
5 — Как развернуть приложение в Kubernetes с werf
6 — Как не потеряться внутри кластера: Service и labels
7 — Ingress в Kubernetes: доступ к приложению извне кластера
8 — Helm-чарт, шаблонизация и никакого хардкода
9 — Как добавить nginx в свой кластер Kubernetes?
10 — Настройки, mounts, ConfigMap в Kubernetes

Плейлисты в YouTube | VK Видео | Rutube

Вы в 70 минутах от уверенного деплоя, сохраняйте себе.

главное как на рекламу - набрали 56 клоунов. а как на хороший материал - 10 лайков всего. соберитесь)

Переносим изменения между несколькими одинаковыми репозиториями

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

1) правим нужное в одной репе
2) git log - забираем <comit hash>
3) git format-patch -1 <comit hash> -> получим файл с патчем
4) намылить-смыть-повторить
while not udovletvoryon; do
cd repoN
git apply ../<source repo>/<patch_name>.patch
done
5) задумываемся о том, что от дублирования кода надо избавляться

С Днём космонавтики! 🚀 Пусть ваши мечты взлетают так же высоко, как ракеты, а новые открытия ждут за каждым горизонтом. К звёздам! ✨

mws terraform

создание вм с cloud-init (этого нет в документации)

resource "mws_compute_virtual_machine" "basebox"

{
os = {
hostname = "basebox"
local_domain = "local"

metadata = {
attributes = {
user-data = file(var.meta)
}
}
}

где meta - стандартный cloud-init файл

лабораторная ansible+vault

Добавил новую лабу по интеграции ansible и vault.
Задача очень простая, предназначена для знакомства с технологиями.
Приведён пример раскатки CIS Benchmasrk ansible role на Ubuntu24.04 с k8s кластером и установленным hashicorp vault на этот же самый кластер, с вынесением пароля grub на vault. Для prod окружений рекомендуется ознакомиться с политиками vault и делать от отдельных УЗ (в примере используется root token)


https://github.com/bykvaadm/CyberEd/blob/master/2/README.md#задание-с--выполнять-после-лекции-8-про-vault

🚀 Скоро: HashiCorp Vault 2.0!

В открытом доступе появился релиз-кандидат HashiCorp Vault 2.0 — первого крупного обновления за долгое время. Вас ждут автоматическая ротация секретов, передовые протоколы PKI и полная интеграция с Kubernetes.

🔐 Главные нововведения

• Автоматическая ротация секретов: Снижение числа инцидентов на 75% и сокращение разрастания учетных данных на 90% благодаря устранению статических кредов и динамической выдаче секретов.
• Передовые PKI-протоколы: Полная поддержка протоколов SCEP, EST и CMPv2 для автоматизации выдачи сертификатов. Теперь подписывать промежуточные сертификаты стало проще, а в alt_names можно использовать глоб-шаблоны.
• Нативная интеграция с Kubernetes: Динамическая инъекция секретов на уровне подов без изменения кода.
• Доработки и исправления: Обновление Go до версии 1.25.7, улучшение статуса sys/seal-backend-status для лучшего мониторинга и поддержка HashiCorp-плагинов как внешних бинарных файлов.

Финальный релиз, как ожидается, окончательно сформирует стандарт управления секретами в эпоху zero-trust. Официальной даты выхода пока нет, но ждать, судя по всему, осталось недолго. (час назад вышел билд на github: https://github.com/hashicorp/vault/releases/tag/v2.0.0)

https://discuss.hashicorp.com/t/vault-2-0-0-rc1-released/77296

• SCIM-провижининг: Полная автоматизация жизненного цикла пользователей и групп через синхронизацию с внешними IDP-платформами.
• Нативная поддержка SPIFFE: Аутентификация рабочих нагрузок с помощью JWT-SVID, что позволяет бесшовно вписаться в экосистему SPIFFE.
• Визуальный конструктор политик: Генерация ACL-политик прямо в веб-интерфейсе Vault. Больше не нужно писать сложные правила вручную.
• Workload Identity Federation (WIF) для синхронизации секретов: Теперь для настройки синхронизации с AWS, GCP или Azure не нужны статичные креды — всё работает через федерацию.
• Расширение для публичных центров сертификации (Public CA): Vault теперь умеет оркестрировать выдачу и управление жизненным циклом сертификатов от публичных CA.
• In-Place Encryption SDK: Шифрование и дешифрование данных на стороне клиента без отправки данных в Vault. Ключевой функционал для конфиденциальных сред.
• Ротация паролей локальных учетных записей: Управление учетными данными локальных пользователей Linux с автоматической ротацией.
• Умная ротация для LDAP: Гибкая настройка ротации статических кредов LDAP: начальные пароли, самоуправляемая ротация, расписания и политики повторных попыток при сбоях.
• Мультикластерные уведомления о событиях: Теперь вы не пропустите ни одного важного изменения в вашей распределенной системе.
• Улучшенный онбординг: Новый GUI помогает быстрее освоить ключевые функции, а процесс создания неймспейсов стал интуитивно понятным.