FROM debian:trixie

Тихо и незаметно вышел стабильный релиз Debian 13 Trixie.
https://www.debian.org/releases/trixie/release-notes/

Особых ожиданий от него не было, кроме желания обновить множество базовых имиджей для устранения накопившегося технического долга по CVE.
Утомительное говно от шизо-сесурити-параноиков в общем.
Сразу протестировал на нескольких проблемных сервисах - Trivy пока не выявил уязвимостей. Отлично.

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

#пятница

Репозитории в 2018

projectdir
projectfiles

Репозитории в 2022

projectdir
projectfiles
IDEA
.gitignore
.dockeringnore
.helmignore
.gitattributes
.pre-commit-config.yaml
.yamllint
.editorconfig

Репозитории в 2026

projectdir...
projectfiles...
CLAUDE.md
.kiro/steering/product.md
.kiro/steering/structure.md
.kiro/steering/tech.md
.cursor/rules/general_rules.mdc
PERPLEXITY_AI.md
.perplexity/settings.yml
.perplexity/guides/how_to_talk_to_ai.md
README_PYTHON_CHATBOT.md
AI_instructions/do_not_argue_with_robot.txt
.grok_instructions.md
notion_ai_policy.md
consensus/verification.md
midjourney/picture_rules.mdc
kill_all_humans.bender
mintlify_update_all_the_documentation_cause_im_lazy_ass.yml

#gitlab #github #secrets #security

История третья. GitHub.

Третья история это не баг репорт, а собственное исследование в целях повышения опыта и экспертизы в вопросах безопасности.
НЕ ПОВТОРЯТЬ, ЭТО ПРОТИВОЗАКОННО, НЕЛЬЗЯ ПОВТОРЯТЬ
История лишь для ознакомления, повторять абсолютно запрещено, заметка исключительно в целях сокрытия СВОИХ проектов от глупых действий.

Все эти игрища были лишь в организации, где изначально у меня были хоть какие-то, но минимальные права.
Будет ли это работать при публичных репозиториях?
Как мне проверить это и защитить свои публичные репозитории от хакеров?

Немного теории. Выжимка для самых маленьких - вы ведь не хотите читать всю документацию GitHub.
1) Когда я запускаю у себя(личный репо, репо организации) воркфлоу - это МОЙ секьюрити контекст.
Мой securitycontext = мне доступны все секреты.
Если я сделаю форк от любого публичного репозитория, затем "что-то подменяю" в коде и отправлю pull request - это Fork а значит недоступен SecurityContext и секреты. То есть при любом форке - секреты недоступны, только если автор репозитория специально руками не сделает это(по умолчанию выключено).
Однако есть директива pull_request_target
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target
Если в каком-то репозитории есть такая директива = при форке и пулл реквесте мы получаем доступ к SecurityContext.
2)GitHub не дурак и отслеживает любые изменения файлов воркфлоу.
Даже если у нас есть pull_request_target, но мы взяли и подменили workflow файл, добавив туда нечто типа run: python scripts/print_secret.py - этих изменений не будет в воркфлоу - есть дифф между оригиналом

Это всё теория, а что насчёт практики.
Чтобы "взломать все интернеты" нам надо соблюдение таких условий
- чтобы была опасная директива pull_request_target - "pull_request_target"
- чтобы директория была - path:.github/workflows/
- чтобы мы могли как-то где-то что-то запустить, НЕ изменяя файл воркфлоу, но заинжектить свой вредоносный код, а точнее защититься от такой ситуации в своих публичных репозиториях.

Как мы можем заинжектить, не меняя ничего в воркфлоу?
Нам надо найти куски кода, где в run есть:
- нечто типа python script.py (подменяем сам скрипт и он выполняется, извлекая секреты)
- pip install (в setup.py инжектим pre-install и выполнение нашего кода, получаем доступ к секретам)
-npm install/command (ну тут понятно - лепи что хочешь)
- всё подобное, что выше, но для других языков/утилит

В двух словах поиск будет типа

org:*****  path:.github/workflows/ "pull_request_target" "${{ secrets." "install"

В общем и целом это помогает злоумышленнику получить доступ к вашим секретам через форк и пулл реквест.
Однако когда я начал писать об этом репорт, я уже решил почитать документацию и везде написано, что такие действия опасные.
То есть тот, кто включил у себя pull_request_target - сам себе злобный буратино.
Та же ситуация с запуском скриптов из всех примеров выше.
Вероятно от https://hackerone.com/ я получу такой же ответ.
Репорт не стал писать. И слишком много условий и в документации есть миллионы ворнингов.

Итоги.
Первые две истории - это реальные репорты с реальным ответом. Все семь репортов мне закрыли с
Informative (Closed). Само собой без каких-либо выплат. Остальные пять репортов я тут публиковать не буду - их них ещё можно протянуть дальше кейсы и попробовать дальше эволюционировать в реальную уязвимость (они уровнем выше, чем эти истории на мой взгляд).
Третья же история это самостоятельное погружение "а как это работает".

Для себя же стоит запомнить:
- никогда не использовать в своих публичных репозиториях pull_request_target - при форке идёт передача SecurityContext и все секреты отдаются публично.
- нникогда не использовать в своих публичных репозиториях запуск сторонник скриптов типа python script.py
- не рассчитывать на сохранность всех секретов GitLab
- я ещё поиграю в хакера и попробую заработать на других потенциальных уязвимостях

И да - я опять поленился писать лонгрид в один пост, сорян.

#zalando #kubernetes #troubleshooting

"Алекс, у нас там проблемы с БД, которая у вас в кубере - приложение не подключается к нему, пишет всякое".

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

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

Читаю поверхностно логи приложения, оператора, кластера БД - всё вроде ок.
Через разрешение рестартую приложение - проблема уходит.
Закрываю тикет, с лицом Дукалиса-солнышко объясняю деткам-разработчикам, что магии не бывает - у вас приложение говно, раз рестарт POD-a с бизнесовым приложением помогает. БД я не трогаю вообще.

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

Не, ну правда - если я вообще не трогаю БД и рестарт бизнес апп помогает - как я мог решить, что виновата инфра?
И потом ситуация ещё пару раз.

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

Логи логи логи. Не буду тратить время на описание, но я бессмысленно потратил несколько дней - и ничего не нашёл. Не зная, что искать - ничего и не находишь.
Жалобы время от времени всё поступали и мы совсем сникли.

Для помощи самому себе так же подняли, не моими силами, сбор метрик не только PostgreSQL, но и Patroni.
Однако метрики ничем не помогли.

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

demoting self because DCS is not accessible and I was a leader

Это была первая зацепка, и следом начал цепляться за всякое типа

20**/12/06 11:30:18 main.go:127: Connection stats - max: 200, used: 12, available: 185 (6.0% used)
20**/12/06 11:30:18 main.go:130: Connection states - active: 3, idle: 6, idle in transaction: 0
20**/12/06 11:30:18 main.go:274: Database in recovery mode: true

Зацепка, отписываем промежуточное мнение:
кластер делает свичовер но НЕ переключает на реплику(мы это видим по IP при ресолвинге)
наши бизнес приложения продолжают сидеть в том же пуле, их не выкидывает и не переключают на мастера
появляются новые пиды, у которых лайфсайкл времени идёт от времени свичовера.

Складывая в пул все найденные логи, какие-то новые для себя слова, я прихожу к
https://patroni.readthedocs.io/en/master/dcs_failsafe_mode.html
О, как это было похоже на то, что у нас происходило.
Не буду пояснять тут, в документации отлично всё расписано.

Проверяем: а есть ли у нас эта алупа:

root@test-db-2:/home/postgres# curl http://localhost:8008/config | jq
...
{
  "failsafe_mode": false,
...

Бл, а оно у нас и не включено.
Иду у чарт
https://github.com/zalando/postgres-operator/blob/master/docs/reference/operator_parameters.md#patroni-options
https://github.com/zalando/postgres-operator/blob/master/manifests/configmap.yaml#L52

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

Проверяем применилось ли это:

kubectl exec -it test-db-0 -- curl http://localhost:8008/config | jq .failsafe_mode
true

и

kubectl get postgresql test-db -o yaml | grep -A 2 patroni
  patroni:
    failsafe_mode: true

Где не применилось, там спасибо оператору, пилим костыль

kubectl rollout restart statefulset test-db

Пару недель тестов - ошибка больше не повторялось. Ура, победа!

#kubernetes #azure #aks #troubleshooting #argo #dapr #api

Ныряем в Azure AKS API.

Часть 1 из 2.

У нас болел кубернетис апи.
Болел долго, со вкусом.
Словно мужчина 30+ лет с температурой 37.2, с опекой рядом кудахтающей супруги.

Мы честно хотели его вылечить, но у меня лично никогда не было глубокого опыта дебага апи, часть команды было просто пофиг. Вроде работает? Хорошо. Бизнес, само собой, такими вещами и не интересуется.
Это вызывало массу сайд эффектов: 4 или 5 из моих историй это следствие загрузки K8S API.
Работа операторов, работа кеды и dcs демоушн.

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

Путь первый. Невежественность.

В кластере много компонентов, которые работают с кубернетес апи.
ArgoCD, Kyverno, десятки операторов. Много всего.
Первый мой шаг - поэтапно вырубать контроллеры
То есть я тупо один за одним вырубал какие-то компоненты.

kubectl scale --replicas 0 sts/name
kubectl scale --replicas 0 deploy/name

и ждал. 30-60 минут, есть ли эффект.
Конечно же предупреждая коллег, и в случае необходимости тут же скейлил вверх.

Эта идея была тупая, я убил несколько часов/дней.
Никакого результата.

Путь второй. Наивность.

Дальше я выбрал путь наивности - ходил по приложениям, операторам и где мог, подкручивал параметры, чтобы обращения к АПИ был реже. Всякие реконсилейшн у арго, демоушн патрони, частота запросов кеда оператора и так далее.
Помогло ли это? Нет. Стало ли лучше? Глобально - да, ведь я просто оттюнил к лучшему.

К пункту наивности я бы добавил все мои попытки разобраться "что не так с апи по метрикам".
Метрики никак и никогда не дают информации кто же даёт основную нагрузку.

Путь третий. Просветление.

Очевидно предыдущие попытки были унылы и тупы.
Почитал интернет, нейронки, документацию.
Первым делом включаю аудит-лог.
Azure-Kubernetes-Monitoring-Diagnostic settings.
Дальше включаю для Kubernetes API и сохранение в Log Analytics workspace.
Сохраняю, иду в Log Analytics workspace.
Там выбираю Logs и ищу сперва все ошибки.

AKSControlPlane
| where Category == "kube-apiserver" and Level == "ERROR"
| limit 40
| project TimeGenerated, Level, Message

Вижу кучу ошибок.
Ок, начнем с рандом частой ошибки:

cacher (subscriptions.dapr.io): unexpected ListAndWatch error: failed to list dapr.io/v1alpha1, Kind=Subscription: conversion webhook for dapr.io/v2alpha1, Kind=Subscription failed: Post "https://dapr-webhook.replaceme.svc:443/convert?timeout=30s": service "dapr-webhook" not found; reinitializing...

Не заостряю внимание на продукте, мне он знаком (можно почитать на https://github.com/dapr/dapr/).
По ошибке проблема сервиса(хоть и странный адрес), а есть ли он?

kubectl get svc -n dapr-system | grep webhook
dapr-webhook            ClusterIP   10.0.12.141   <none>        443/TCP                                

Он есть.
Почему возникает эта ошибка?Сперва смотрю валуес

helm show values dapr/dapr --version 1.14.2

Нет ничего интересно, как и в нашем values файле.
Иду в чарт и качаю его к себе https://github.com/dapr/helm-charts/blob/master/dapr-1.14.2.tgz
Вижу кучу темплейтов, хелперсов, CRD.
В CRD указано, что сам оператор реплейсит CRD.

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
  group: dapr.io
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        service:
          namespace: replaceme # Patched by post-install webhook

То есть оператор время от времени должен реплейсить неймспейс внутри CRD с replaceme на реальный dapr-system.
А он не реплейсит. Хорошо, меняю сам руками, смотрю результат.

kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: dapr-system

Радуюсь, иду в логи - а там снова ошибка.
Непонятно. Возвращаюсь обратно а там

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: replaceme

Да камон.

#kubernetes #azure #aks #troubleshooting #argo #dapr #api

Часть 2 из 2.

Думаю ну может я дурак, Меняю снова, уже не иду в логи, А проверяю на месте.
И картина там такая:

kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: dapr-system

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: replaceme

Бррр, как такое возможно.
Иду в гугл, нейронку, мне говорят "а ты посмотри - кто последний то меняет объект?".
Смотрю

kubectl get crd subscriptions.dapr.io -o jsonpath='{.metadata.managedFields[*].manager}' | tr ' ' '\n' | sort | uniq -c
      1 argocd-controller
      1 kube-apiserver
      1 kubectl-edit
      1 operator

Пффф, а арго то тут причем?
Снова меняю, снова смотрю - да, арго меняет обратно неймспейс на дефолт.
Иду в репозиторий арго, но там просто

---
name: dapr
namespace: dapr-system
repoURL: https://dapr.github.io/helm-charts/
targetRevision: 1.14.2
chart: dapr

Ну и applicationset есть.
А больше мы ничего не меняем.
Снова документация, гугл.
Оказалось вот что:
- арго выкачивает ВЕСЬ чарт, внутри есть директория CRD и там внутри дефолт(путь к чарту был выше, внутри есть CRD директория с манифестами).

Промежуточное описание проблемы:
каждый N период времени оператор DAPR меняет namespace в CRD, тут же сам applicationset DAPR переходит в OutOfSync, арго начинает резко синкать, подтягивает весь чарт, видит, что поменялся CRD и меняет на дефолт. И так по кругу. Насилие ради насилия.

Я и коллега начали фиксить это несколькими вариантами через applicationset, типа

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
...
  template:
...
    spec:
...
      ignoreDifferences:
...
        - group: apiextensions.k8s.io
          kind: CustomResourceDefinition
          name: subscriptions.dapr.io
          jqPathExpressions:
            - .spec.conversion.webhook.clientConfig.service.namespace

Затем снова руками меняю неймспейс, смотрю - ура.
Неймспейс больше не ревратится, в аудит логе АПИ ошибки(этой) больше нет.
Да, арго больше не меняет.

Нагрузку снизили на ... на 4%. Мало, но уже что-то.
Выключаю аудит лог(он оооооооооочень дорогой), закрываю одну из саб-тасок касательно АПИ.

Ещё раз описание ишшуи:
- задеплоили арго аппликейшнсет через сторонний чарт с DAPR
- арго создаёт все сущности через хелмп темплейт (даже те, о которых мы в явном виде не знали)
- затем вебхук от оператора дапр переписывает CRD
- арго при синке видит дифф по CRD и переписывыает его снова
- и так по кругу
Пока не глянешь в кишки и не добавишь в игнор - насилие над апи кубера, так как весь функционал арго и дапра - через кубер апи.

Итог:
- я научился смотреть в логи аудита по Azure AKS API
- сгорел от дурости DAPR оператора и ArgoCD оператора в попытках переписать друг за другом CRD
- узнал про игноры в арго (вообще есть и иные решения для проблемы, но игнор самый простой)
- снизил нагрузку на 4% лишь с одним фиксом

Впереди ещё несколько подходов к апи, есть десятки других ошибок, буду с каждой разбираться отдельно.
Это оказалось интересно.

#kubernetes

Тупости и лени пост.

Иногда бывает такое, что кластер обновился, развалился, автоматически секьюрити апдейтнулся(аригато, Azure), руками апгрейднулся(аригато, AWS, за принудительно-добровольные апгрейды, иначе денег-денег-денег дай).
Всё тоже самое, но с релизами приложений.
Выбрать любое.

После этого события у нас иногда сразу многое не работает и прилетает куча разных алёртов, ошибок, миллион ивентов.
Побуду бесплатным адвокатом AWS, такое крайне редко, чаще в Azure проблемы.

Проблема: в моменте не очень понятно - а куда вообще смотреть, чего чинить первым?

1) Я сразу по заранее сохранённой ссылке в alertmanager, где стоит фильтр по кластеру(ам) и, иногда severity.
Фильтр cluster=~".*prod.*"
Ссылка формата
+ есть аналог дашборда в графане, но по привычке лезу сразу в alertmanager.
Grafana красивее, нагляднее и удобнее, но привычка дело такое.

Тут ничего для всех нового, но алертов СЛИШКОМ много. Надо как-отфильтровать последнее.

2) Иду в кластер(ы) и одним махом очищаю всё, что мне помешает Быстрой диагностике.
Да, я знаю потенциальные последствия, на 100% их понимаю, что делают команды.
У меня есть алиасы формата

alias kkndp="k delete pod --field-selector 'status.phase!=Running' -A --force"

alias kkndj="kubectl delete jobs --all-namespaces --field-selector status.successful=0"

Я прям иногда ввожу kkndp && kkndj в шелле.

Что это даёт мне:
- все подвисшие/unknown/комплетед/файлед и так далее поды уходят в небытие и мне просто глазами визуально удобнее следить/чинить то, что надо, а не что исторически не релевантно
- все файлед джобы от кронджобов подчищаются и перестают лететь тонны алертов о незавершенных джобах.

Цель: быстро избавить визуальное пространство от "мусорных" исторических алертов и failed объектов, чтобы быстрее найти и починить главное и актуальное.

3) При необходимости смотрю ивенты, с фильтром по времени и не нормал северити

alias kwe="k get events -A --sort-by='.metadata.creationTimestamp' | grep -v Normal"

4) Снова иду в графану/алертменеджер, смотрю, что осталось(обычно 90-95% шума улетает сразу) и чиню релевантное оставшееся.

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

- если у нас не собираются где-то все ивенты и логи, то мы теряем историю и причины, почему был failed, unknown, crashloopback etc. Если всё логируется, то пофиг, разве что exit code/reason мы не увидим(а оно нам надо? итак видно, что кластер обновился).
- если у нас есть velero (https://velero.io/), то есть не иллюзорный шанс проетерять потенциальные бекапы. Например POD velero висел в pending, ожидая ресурсов(или иная причина), а я его убиваю.
Значит бекап, который должен был запуститься, будет запущен при следующем расписании. А сейчас его не будет.
В пендинге он может висеть, например, потому что разом запустилось по расписанию 100500 подов бекапа и упираемся(временно) в количество PVC/disk на ноде/нехватка нод во время апдейта.
Спустя время это проходит, но мои действия потенциально убивают штатный бекап.
С велеро я беру все риски на себя, осознавая, что он скоро (пере)запуститься и бекап будет готов. Так же у нас есть алерты по велеро, так что мне ок.

Возможно стоит переделать алиасы, добавив xargs и добавив в игнор велеро, но пока руки не дошли.
Да и не так часто такие ситуации бывают.

#ocr #ats #cv #ai #ASCII #PDF

Возможно кто-то из инженеров сейчас сидит и не может найти работу, потому что его CV в PDF файле не могут распарсить AI боты и ATS. Банальный баг и невнимательность.

Внезапно узнал, что если вы, как и я, создаёте шаблон CV в MS Word, а потом сохраняете как PDF, то есть бага.

Word -> print as PDF = ❌ non-ASCII characters
Word -> save as PDF = ✅ всё ок (кроме сраных длинных типографских тире)

С печатью в PDF, например, вместо сочетания TI/ti будет спецсимвол.

documenta�on, suppor�ng, GitHub Ac�ons

Ровно как и все типы минусов/дефис/тире (их вроде около 5-6 типов).

Быстро советы:
- НЕ используйте печать как PDF для сохранения документа
- сделал PDF(любым способом) - открыл PDF - выделил всё ctrl+A - скопировал ctrl+c - вставил на странице https://pages.cs.wisc.edu/~markm/ascii.html - и так до тех пор, пока не будет спецсимволов.

Сейчас всё обрабатывают роботы при первичном скрининге.
Дайте роботам шанс дотащить ваш CV хотя бы до HR, сделайте его читаемым.❤️

Ссылки на почитать(опционально):
- https://pages.cs.wisc.edu/~markm/ascii.html
- https://my.onu.edu/sites/default/files/applicant_tracking_system_resume_guide.pdf
- https://careerservices.uic.edu/wp-content/uploads/sites/26/2017/08/Ensure-Your-Resume-Is-Read-ATS.pdf
- https://drive.google.com/file/d/1X5pOmi-s_ZIKPkKsVVElWhSjv80ihyS5/view