Azalio_tech

#физика #научпоп Нано-фемто-пико и остальная порнография. Какая связь между современной физикой и магией из книжек? Ну конечно: «Любая достаточно развитая технология неотличима от магии». © Артур Кларк - третий закон Кларка. Поэтому я и люблю современную физику. Вопрос «это что такое?» здесь возникает постоянно. Лестница длиннее гаража. Влезла она целиком или нет? «Нет, конечно» - мимо. Разгони лестницу: по теории относительности она сжимается вдоль движения и помещается. «Тогда да» - снова мимо. С точки зрения самой лестницы это гараж летит навстречу и сжимается, так что не влезает уже точно. Оба ответа верны. И оба неверны. Зависит от системы отсчёта. Вот это лёгкое «ЭТО ЧЕ» - и зажигает. Я угодил ровно в тот стык на меме сверху, где уютная «понятная» физика заканчивается и начинается XX век. Про этот стык - мини-курс «Современная физика без формул» от Дмитрия Наумова (физик ОИЯИ, возглавляет нейтринную программу). Три лекции по два часа, формул почти нет. Три вопроса оттуда - ответы там же. - Лекция 4.1, «Три интеллектуальные революции»: та самая лестница - частный случай. Где классика упёрлась в стену и почему дальше без квантовой механики, СТО и ОТО уже никак. Замедление времени, гравитационные волны, открытие первого кванта энергии - оттуда. - Лекция 4.2, «КТП: бесконечные мучения и глоток надежды»: почему два электрона отталкиваются. «Одинаковые заряды» - это не ответ. А что именно их отталкивает? - Лекция 4.3, «Стандартная модель» - мой любимый вопрос: из чего складывается масса протона. Ответ «из кварков» - очень, очень приблизительный и почти неверный. Доля самих кварков в массе протона ничтожна. Куда делось остальное - в лекции. Прям советую: https://www.youtube.com/playlist?list=PL28BG43DETPSpmnPCM4VcXoSjZ7y_BCcH P.S. В конце третьей анонсирована четвёртая. «ЭТО ЧЕ» продолжается - жду.

В @kubernetes_ru про Dirty Frag (новая LPE, container escape) - пара сообщений: воспроизводится в EKS, mitigation никто не предложил. Я сам сейчас налаживаю у себя процесс отслеживания CVE и митигаций - вижу ту же проблему: CVE прилетает, готовых ответов нет, каждый разбирается сам. Полез смотреть программу БеКон 2026 - конфы строго про безопасность контейнеров. Нашёл три доклада под эту задачу: SLSA от CI до Runtime (Дмитрий Рыбалка, Mindbox) Supply chain / верификация цепочки поставки. В марте хакнули Trivy - «тот самый, который вроде как секьюрити сканер». Доклад про то, как строить доверенную цепочку от сборки до runtime. PARSEC: свой мандатный контроль для контейнеров (Антон Баранов, ГК АСТРА) Доклад через внутренности containerd/runc — как Астра делает собственный MAC, альтернативный AppArmor/SELinux. AppArmor в community обсуждают регулярно, про PARSEC - почти тишина. Фреймворк JCSF (Дмитрий Селезнев, Инфосистемы Джет) Переход от «прилетела CVE -> судорожно ищем mitigation» к выстроенной системе и playbook. Прямо то, чем сам сейчас занимаюсь. 2 июня, Москва. https://bekon.luntry.ru/ В @kubernetes_ru по mitigation - тишина. На БеКоне - не готовый ответ на Dirty Frag, а три уровня для системного подхода: артефакт, runtime, процесс. Пост по просьбе @k8security. Выбор докладов и текст мой.

# FOMO Цикл статей про промптинг, скиллы и работу с LLM, объяснённые через лингвистику и теорию текста. Открыт во вкладке уже три месяца, и я к нему так и не вернулся. Таких вкладок у меня больше двух сотен. А в телеге несколько тысяч непрочитанных сообщений в сотне каналов, я уже не считаю. Открываю тг, глаза сами бегут вниз по списку, что бы такое прочитать первым, и через минуту уже не помню, зачем заходил. А знаете, сколько статей по AI и около выходит в день? Десятки. И это только на arXiv. Как всё это прочитать? А осознать? НИКАК. И каждая такая вкладка, может быть, ровно то, что решает задачу, над которой я прямо сейчас сижу. Я просто никогда туда не доберусь. Вот так FOMO и выглядит. Информации столько, что она перестаёт помогать и начинает парализовать. Я в этом довольно долго варился. Неделями возвращался к одним и тем же вкладкам, скроллил три экрана, закрывал, а на следующий день открывал заново. В какой-то момент я решил: раз LLM ускорило поток информации, пусть LLM его и разгребает. Я настроил себе бота. Он собирает поток из RSS, Telegram, HN, Reddit и arXiv, дедуплицирует, суммаризирует и складывает всё в мой публичный канал. Код: https://github.com/azalio/azalio_tech_summary Канал: https://t.me/azalio_tech_summary Полегчало, но не до конца. Потому что дальше я выцеплял из этого потока интересное и отправлял в Obsidian. А там оно тоже тихо умирало. Просто уже не во вкладках, а в аккуратно разложенной свалке. Поэтому я навернул сверху ещё один слой. Автоматика сама выбирает из заметок, что стоит притащить в пет-проекты, и дальше сама пилит. Я получаю PR в почту. Например, прямо сейчас в одном из проектов уже проверены десятки научных статей по RAG. Не "когда-нибудь прочитать", а "что из этого реально работает для моего проекта". Кажется, это лучшее, что я пока придумал против FOMO. Не победить поток. А поставить на него фильтр, мясорубку и маленький конвейер до PR.

Что-то придумалось :)

Я третий день в шоке от https://openclaw.ai/ Столько всего уже сделал с помощью агента и мне все больше нравится. Призываю вас, попробуйте. (Использую гемини флеш 3).

Пишу я тут систему AI ревью кода, а то больно смотреть как коллега ревьювит диффы на 35к строк. Чтобы понять а какую модель вообще стоит брать прогнал тесты на 17 моделях. Результаты оказались с одной стороны закономерные, с другой нашлось место и неожиданностям. Вот большой отчет. Выводы: - GPT‑5.2 — лучший баланс “находит баги / не сходит с ума / стоит адекватно”. - Gemini 3 Flash — примерно такое же покрытие багов, но гораздо дешевле и быстрее; особенно хорош на перформанс‑ и инфраструктурных штуках. - Claude Opus 4.5 — премиум по качеству и аккуратности, но дороже GPT‑5.2 при похожем recall. - Gemini 2.5 Pro — лучший “бюджетный рабочий конь”: аккуратные findings, высокая precision, смешная цена. - DeepSeek V3‑2 / GLM‑4.5 — нишевые “охотники за редкими багами”: мало известных багов, но иногда попадание в то, что остальные пропускают. - Часть моделей (O4‑mini, Qwen‑Max, Grok‑3/4, GPT‑4.1‑nano) не годятся как единственный gatekeeper: спокойно говорят APPROVE при наличии критических дефектов. #ai #llm #codereview #devtools #backend

Тем временем внезапно на сайте devoops появилась запись моего выступления.

Вряд ли я это произнесу со сцены, но мне нравится шутка.

CNI chaining — как секс у подростков: все про него говорят, но на деле почти никто не пробовал». И самое смешное — те, кто пробовал, сделали это неправильно.

Ну, поехали 🙂 https://aot-kuberconf.ru/

Я думаю вас никогда так не рикролили :) Рассказываю сегодня про l2 анонсы в #cilium.

GKE metadata-proxy: элегантный способ выдачи JWT без дыр в RBAC Недавно беседовали с коллегой про Workload Identity Federation в GKE и выяснилось, что не все знают, как metadata-proxy получает JWT токен от имени пода. А вы знаете, как это работает под капотом? Что такое WIF? Простая идея: токен пода обменивается на cloud token для доступа к облачным API. Никаких статических ключей! Два подхода к безопасности: ❌ Небезопасный подход (как в эмуляторе):

rules:
- apiGroups: [""]
  resources: [serviceaccounts/token]
  verbs: [create]

Критическая уязвимость! Такая роль позволяет получить JWT токен от ЛЮБОГО ServiceAccount в кластере! ✅ Элегантное решение GKE: 1. Использует kubeconfig от kubelet (у него есть права только на поды своей ноды) 2. Запрашивает токен с указанием реально существующего объекта в кубере, который к тому же привязан к конкренной ноде:

kubectl create token azalio-meta-sa \
    --namespace azalio-meta \
    --bound-object-kind Pod \
    --bound-object-name test-pod \
    --bound-object-uid 5094d128-8f9b-463d

Почему это безопасно? - metadata-proxy может получить токен только для подов на своей ноде - Токен привязан к конкретному поду через UID - Нет доступа к ServiceAccount подов других нод **Как работает весь процесс:** (картинка в комментариях)

1. Pod → metadata-proxy: GET /computeMetadata/.../token 2. proxy → K8s API: create token (ограничен нодой + Pod UID) 3. proxy → Google STS: обмен JWT → Access Token 4. STS → proxy → Pod: Access Token 5. Pod → Google API: работа с нужными сервисами

Полезные ссылки: - Официальная документация GKE Workload Identity - Детальный разбор безопасности WIF - Пример настройки WI в GKE - Bound service account tokens. Что запомнить: Прав выдаваемых kubeconfig'у kubelet хватает чтобы выписать токен от имени SA пода запущенного на ноде. Вопрос: у какого российского облачного провайдера есть WIF? 😉 #kubernetes #security #gke #workloadidentity #cloudsecurity

Да не пропал я никуда! Не пропал! Вот, положила: https://t.me/azalio_tech_summary

😠 Агент-лимитер “слепнет” после появления новых PV? Раз и навсегда разбираемся с `mountPropagation` в Kubernetes! Недавно писал I/O-лимитер для LVM-томов: агент читает маунты подов, чтобы вычислить MAJOR:MINOR для добавления в io.max, и всё ок… пока на узел не приедет новый Pod. Его маунта агент уже не видит. Перезапуск помогает, но это же костыль! Почему так происходит * Каждый контейнер стартует в своём *privаte* mount-namespace -> изменения на хосте туда не пролетают. * В Kubernetes это равно mountPropagation: None. Как починить? Параметр mountPropagation у volumeMounts имеет 3 режима: * None - полная изоляция (`rprivate`), дефолт. * HostToContainer - маунты летят *с хоста -> в контейнер* (`rslave`). Нам нужен именно он. * Bidirectional - маунты ходят в обе стороны (`rshared`). Работает *только* в `privileged`-контейнере, иначе Pod не стартует. Спека

spec:
  containers:
  - name: my-agent
    image: my-agent-image
    volumeMounts:
    - name: kubelet-pods
      mountPath: /var/lib/kubelet/pods
      mountPropagation: HostToContainer
  volumes:
  - name: kubelet-pods
    hostPath:
      path: /var/lib/kubelet/pods
      type: Directory

Теперь каждое *новое* bind-mount событие внутри /var/lib/kubelet/pods мгновенно видно агенту - без рестартов. Что происходит под капотом 1. Kubelet видит HostToContainer и пишет в CRI PROPAGATION_HOST_TO_CONTAINER. 2. CRI-shim (containerd/CRI-O) делает каталог rslave. 3. Все будущие маунты, созданные kubelet’ом на хосте, автоматически “проливаются” в контейнер. На заметку * Bidirectional опасен в мульти-тенант окружениях: контейнер может пролить маунты *на хост*. * В Kubernetes 1.10 было краткое время, когда дефолтом неожиданно стал HostToContainer. Если админите древний кластер - проверьте (хотя боюсь вам уже ничего не поможет...). * Cilium тоже использует этот трюк чтобы следить за bpf мапами. Полезные ссылки • Документация • CRI интерфейс • man mount #kubernetes #k8s #mountPropagation #linux #devops #storage

🔒 Отключаем анонимный доступ к kube-apiserver, но оставляем health checks! Привет! Недавно ко мне пришел коллега-безопасник (Дима привет!) с интересным вопросом: как полностью отключить анонимный доступ к API-серверу Kubernetes, но оставить рабочими проверки /livez, /readyz и /healthz? 🤔 Сходу не ответил, полез копаться в исходниках и KEPах. Проблема в том, что по умолчанию (`--anonymous-auth=true`) любой может дернуть эндпоинты health-чеков и не только health-чеков:

curl -k https://<API_SERVER_IP>:6443/livez
# Output: ok

Это удобно, но создает потенциальный вектор атаки, если RBAC настроен не идеально или найдется уязвимость. Безопасники такое не любят. 😟 К счастью, в KEP-4633 сообщество Kubernetes предложило решение! Теперь можно тонко настроить, к каким путям разрешен анонимный доступ, даже если глобально он выключен. Сделать это можно так: Сначала выключаем глобальный анонимный доступ в манифесте kube-apiserver:

    spec:
      containers:
      - command:
        - kube-apiserver
        # ... другие флаги ...
        - --anonymous-auth=false # <--- Выключаем!
        - --authentication-config=/etc/kubernetes/auth-config.yaml # <--- Указываем конфиг
    

Затем создаем файл конфигурации /etc/kubernetes/auth-config.yaml на control plane нодах и монтируем его в под kube-apiserver:

    # /etc/kubernetes/auth-config.yaml
    apiVersion: apiserver.config.k8s.io/v1beta1
    kind: AuthenticationConfiguration
    anonymous:
      enabled: true # Включаем анонимный доступ *только* для указанных путей
      conditions:
      - path: /livez
      - path: /readyz
      - path: /healthz
    

*(Не забудьте добавить volume и volumeMount в манифест kube-apiserver для этого файла)* В итоге получаем: - Запросы к /livez, /readyz, /healthz проходят как system:anonymous. - Запросы к другим путям (например, /apis) без аутентификации получают 401 Unauthorized. Кстати, эта функциональность появилась как Alpha в Kubernetes 1.31 и стала Beta в 1.32. Теперь можно спать спокойнее, зная, что анонимный доступ под контролем! #kubernetes #k8s #security #authentication #kubeadm #devops #infosec

Простите за репост, но это божественно.

Говорят, в этом канале собрались очень умные люди. Поэтому поступило предложение рассказать про митап, который устраивает Магнит OMNI и я не нашел поводов отказаться. — 23 апреля встречаемся на митапе в Магнит OMNI! Ивент, на котором инженеры, администраторы и разработчиками обсудят, как сделать инфраструктуру устойчивой к сбоям, как развивать Observability в условиях распределенной инфраструктуры и какие внутренние протоколы помогают, когда все идет совсем не по плану. 🔸 Что будет: — Спикеры из Магнит OMNI, Лаборатории Касперского, Авито, Cloud.ru и других компаний — Разбор болей, кейсов и решений, которые работают. — Розыгрыш призов от Магнит OMNI. — Живой нетворкинг. Митап можно посетить: — Офлайн в московском офисе Магнита, — Онлайн 📅 Дата: 23 апреля 🕔 Время: 17:30 Не упускайте возможность узнать новое и пообщаться с профессионалами! Подробности и регистрация — по ссылке. #OMNI_events @magnit_omni_team