Опасные места в YAML

YAML позиционируется как человекочитаемый формат данных, но при этом это склад подводных камней. Рассмотрим самые тупые особенности, которые могут привести к неожиданным ошибкам.

Шестидесятеричные числа

port_mapping:
  - 22:22
  - 80:80
  - 443:443

Что вы ожидаете увидеть? Скорее всего, список строк для настройки портов. Но YAML 1.1 интерпретирует 22:22 как шестидесятеричное число и превращает его в 1342. В YAML 1.2 эту "фичу" убрали, но многие парсеры до сих пор используют старую версию.

Проблема Норвегии

countries:
  - dk
  - fi 
  - is
  - no  
  - se

Код страны Норвегии no будет интерпретирован как булево значение false. То же самое произойдет с off, n, yes, on, y в различных вариантах написания. Классическая ловушка, получившая название "Norway Problem".

Случайные числа

versions:
  - 9.5.25  # строка
  - 9.6.24  # строка
  - 10.23   # Число!
  - 12.13   # Тоже число!

Строки без кавычек могут неожиданно стать числами. 10.23 превратится в float, а 9.5.25 останется строкой, потому что имеет "слишком много" точек.

Ключи не только строки

settings:
  on: [push, deploy]
  priority: high

Здесь on интерпретируется как булево true, поэтому ключом становится не строка "on", а логическое значение. В JSON это может превратиться в "True" или вызвать ошибку.

Теги и небезопасность

user_data: !python/object/apply:subprocess.check_output [['rm', '-rf', '/']]

Теги, говорят, иногда полезны, но при определенных условиях позволяют выполнять произвольный код при загрузке. Всегда используйте safe_load вместо load в Python и аналогичные безопасные методы в других языках.

Получил свой первый сертификат по кубу. Теперь я сертифицированный кубовод)

Привет!
Коллеги проводят исследование, чтобы понять, что реально происходит внутри ИТ-команд и какие закономерности можно в этом увидеть.

Уже нащупаны интересные корреляции:
– между скоростью пайплайнов и качеством code review,
– между алертингом и стабильностью релизов,
– между ролями в команде и удовлетворённостью релизным процессом.

Но нужно больше данных, чтобы отделить закономерности от шума.

Пройти анкету можно за 10 минут. Её же можно использовать как мини-чек-лист для самооценки зрелости инженерной культуры.

Принять участие: https://forms.gle/NszR7VDuXL9sBbVAA

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

P.P.S. Довольно давно не выходило моих постов про инфру — подготовка идет полным ходом. Скоро возобновлю регулярные посты про кубер в проде

Создание production кластера kubernetes под управлением Talos Linux

Начинаем цикл видео про production ready k8s кластер

YouTube — https://youtu.be/_QwJRZa52QU
ВКВидео — https://vkvideo.ru/video-232188619_456239018
Ну и буду прикреплять к посту в Telegram

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

P.S. Забыл в видео удалить токен после flux bootstrap. Не забудьте это сделать!

Полезные ссылки и информация, которые вам потребуются при просмотре видео:

Proxmox terraform provider. Документация по добавлению пользователя для terraform

Репозиторий с конфигами для terraform

Установка talosctl

Установка kubectl

Установка helm

Установка flux

Talos Image Factory

Установка cilium в кластер talos

Flux Bootstrap Gitlab

Доклад про Talos от Дмитрия Рыбалки

Список разрешений для пользователя terraform:

SDN.Use, VM.Monitor, Datastore.AllocateSpace, VM.Clone, VM.Allocate, VM.Config.Options, VM.Config.Memory, VM.Config.HWType, VM.Config.CPU, VM.Config.Cloudinit, VM.Config.Disk, VM.PowerMgmt, Datastore.Audit, VM.Config.Network, VM.Config.CDROM, VM.Audit

.terraformrc:

provider_installation {
  network_mirror {
    url = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Команда для flux bootstrap:

GITLAB_TOKEN=<токен> flux bootstrap gitlab \
  --owner=<repo_group> \
  --repository=<repo_name> \
  --path=cluster \
  --hostname=gitlab.example.com \
  --components-extra='image-reflector-controller,image-automation-controller' \
  --read-write-key \
  --deploy-token-auth

Процесс обновления Talos Linux

YouTube — https://youtu.be/ikiPtVs78YI
ВКВидео — https://vkvideo.ru/video-232188619_456239020

Команды, которые вам потребуются:

Просмотр списка доступных нод — kubectl get nodes -o wide

Обновление Talos — talosctl -n <ip ноды> upgrade -i registry.example.com/talos:1.11.3

Talos Dashboard - talosctl -n <ip ноды> dashboard

Обновление image в конфигах Talos — sed -i "s|factory.talos.dev/metal-installer/6adc7e7fba27948460e2231e5272e88b85159da3f3db980551976bf9898ff64b:v1.11.2|registry.example.com/talos:1.11.3|" *.yaml

Поднятие локального docker registry — docker run -d -p 5000:5000 --restart always --name registry registry:3

А вот и результаты опроса подъехали!

А вот и аналитика по инженерной зрелости компаний(статья на хабре), в которой многие из вас участвовали.
Помните мы устраивали опрос?
Большое спасибо всем кто принял в нем участие.
Ответ каждого из вас сделал эту статью более глубокой и честной.

А вот вам выводы для затравки
1) Для роста нужно не геройство, а системность
2) мы релизим так же хреново как ведем документацию. (такая вот авторская интерпретация подтвержденная цифрами)

притяного чтения)

PS. спасибо ребятам осуществлявшим информационную поддержку, без вас результаты были бы в разы скромнее)

Смотрю интересный стрим от ребят из Cozystack. Присоединяйтесь!

https://www.youtube.com/watch?v=hl9LMcxg1qM

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

Я уже упоминал на канале такой продукт, как Cozystack. Давайте смотреть как же он устроен.

https://www.youtube.com/watch?v=fzA3WxoZFYg

Устанавливаем Flux через Flux

Сегодня будем переводить Flux под управление его же самого. Чтобы у нас был настоящий GitOps

YouTube — https://youtu.be/023CIvGaDTA
ВКВидео — https://vkvideo.ru/video-232188619_456239021
Текстовая версия — https://etherlord.org/posts/переводим-fluxcd-под-управление-fluxcd/

Коммит с изменениями в рамках этого поста — тык сюда.

С наступающим!

Пора подвести итоги года. Они на картинке :)

Всех с наступающими праздниками!

Декабрь был трудным, потому ничего не писал. Надеюсь после праздников возобновить регулярные посты и продолжить цикл по production ready k8s

Удаляем FluxCD манифесты, которые были созданы при первоначальном бутстрапе

В этом году было достаточно сложно раскачаться и войти в рабочий ритм. Но у меня получилось :)

Первый пост в этом году будет маленький, как дополнение к предыдущему.

После того как мы перевели Flux под управление самого себя — была забыта одна вещь. А именно — нам нужно удалить старые манифесты, которые записал Flux в репозиторий, когда делался первоначальный bootstrap. Они нам теперь не нужны.

Исправляемся — коммитим, пушим, убеждаемся, что все работает.

Путь миграции с flux bootstrap на flux operator описан в официальной документации flux operator. То, что мы сейчас делали описано в разделе Cleanup the repository

На след. неделе будем передавать Cilium под управление Flux

Переводим Cilium под управление FluxCD

YouTube — https://youtu.be/pYZN_wMk5qk
ВКВидео — https://vkvideo.ru/video-232188619_456239022
Текстовая версия — https://etherlord.org/posts/переводим-cilium-под-управление-fluxcd/

Коммит с изменениями в рамках этого поста — тык

На следующей неделе поста не будет. В комментариях под прошлым постом мне предложили сделать AI продукт, который бы настраивал простые сервера. Мне кажется такой продукт не особо нужен, поэтому 22 февраля (воскресенье) в 18:00 Мск проведем стрим. Покажу как с помощью Claude Code можно настраивать сервер. Также покажу более правильный, на мой взгляд, подход, в котором мы, совместно с ИИ, напишем Ansible Playbook, который будет делать тоже самое, но при этом у нас останется артефакт в виде кода и его можно будет многократно применять для настройки однотипных серверов

Стрим по AI Ops!
22 февраля в 18:00 Мск

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

Рассмотрим два подхода:

1. Даем ИИ полный доступ к серверу
2. Просим сгенерировать ansible playbook и сами его проверяем

Мы будем настраивать простой сервер с помощью Claude Code.
Это связка nginx + docker. Сделаем простой деплой с помощью Gitlab CI.

YouTube — https://www.youtube.com/watch?v=U9w0xsejL8Y
ВКВидео — https://vkvideo.ru/video-232188619_456239024

До встречи на стриме!

Начинаем!

Внезапнопост или HEREDOC в Docker без buildx

В нескольких постах на канале я топил за использование HEREDOC синтаксиса в Dockerfile

Смотрите как красиво, никаких && и \ (ну почти):

RUN <<EOF
    set -e
    apt-get update
    apt-get install --no-install-recommends -y \
        openssh-client \
        rsync \
        non-existent-package
    apt-get clean
EOF

Но с этой фичей уже была одна проблема - тык

Сегодня с коллегой раскопали еще одну — оказывается если вы поставили docker без плагина buildx, то при сборке все инструкции внутри HEREDOC будут просто молча проигнорированы. Могли бы хоть ошибку вывести

Такой вот подарочек от разрабов docker. Будьте внимательны и удачных вам сборок!

Если ещё беспокоитесь за copy.fail в своих кластерах - вот изи-фикс.

Маленький DaemonSet, грузит BPF-LSM хук на socket_create и режет любые попытки открыть AF_ALG. Без ребута, без пересборки ядра, без правки cmdline.
Работает на Talos Linux, где rmmod архитектурно недоступен (SELinux + lockdown + контроллер не умеет unload).

Ставится одной командой:

kubectl apply -f https://raw.githubusercontent.com/cozystack/copy-fail-blocker/main/manifests/copy-fail-blocker.yaml

https://github.com/cozystack/copy-fail-blocker

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

Dirty Frag is a case that extends the bug class to which Dirty Pipe and Copy Fail belong. Because it is a deterministic logic bug that does not depend on a timing window, no race condition is required, the kernel does not panic when the exploit fails, and the success rate is very high.
. . .
The xfrm-ESP Page-Cache Write vulnerability is in scope from cac2661c53f3 (2017-01-17) up to upstream, and the RxRPC Page-Cache Write vulnerability is in scope from 2dc334f1a63a (2023-06) up to upstream.

In other words, the effective lifetime of the vulnerabilities is about 9 years.

This Dirty Frag has been tested on the following distribution versions.

Ubuntu 24.04.4: 6.17.0-23-generic
RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
openSUSE Tumbleweed: 7.0.2-1-default
CentOS Stream 10: 6.12.0-224.el10.x86_64
AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
Fedora 44: 6.19.14-300.fc44.x86_64

https://github.com/V4bel/dirtyfrag

Mitigation

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Вот это вообще балдёж

> Because the embargo has currently been broken, no patch or CVE exists.

Поздравляю всех подписчиков с началом лета! И вручаю вам тёплый летний подарок: методичку по харденингу Ubuntu 24.04 на русском.

Методичка - моего авторства (@bykva)
Долгие и нудные часы чтения 1000-страничного CIS и публичной ansible роли зародили во мне идею - вот бы была готовая выжимка, по которой можно было бы настроить автоматизацию, при этом понимать что именно она выполняет. и сделать это за 1 день, а не за несколько недель.

В итоге родилась она - сжатая выжимка тысячестраничного CIS Benchmark: по каждому пункту коротко - что и зачем настраивать, с выделенными нюансами и ссылками на источники.

Внутри - более подробное описание что это и зачем.

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