#devops #certificate

Простая напоминалка (в том числе и себе) на 2026-2027 годы про TLS‑сертификаты.

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

Кратко по таймлайну (публичные TLS, CA/B Forum):

398 > 200 дней (с марта 2026) > 100 дней (с 2027) > 47 дней (с 2029).

Параллельно сокращают сроки повторного DCV, к 2029 остаётся до ~10 дней на переиспользование проверки домена.

CA (официальные анонсы и FAQ):
- DigiCert - переход на 199‑дневные сертификаты:
https://knowledge.digicert.com/alerts/public-tls-certificates-199-day-validity
- DigiCert - FAQ по срокам валидности:
https://www.digicert.com/faq/tls-ssl-certificate-validity
- Sectigo - про риски и 200‑дневную валидность:
https://www.sectigo.com/blog/200-day-ssl-certificate-expiration-risk
- GlobalSign - 199‑дневные сертификаты с марта 2026:
https://www.nicsrs.com/blog/globalsign-199-day-ssl-certificate-validity-2026

ACME / Let’s Encrypt и короткоживущие серты (думаю такое у многих):
- Let’s Encrypt: с 90 до 45 дней, общий план:
https://letsencrypt.org/2025/12/02/from-90-to-45.html
- Разбор перехода на 45‑дневные серты:
https://www.certkit.io/blog/45-day-certificates
- Let’s Encrypt: 6‑дневные и IP‑сертификаты (интересно в контексте мира с 47 днями):
https://www.helpnetsecurity.com/2026/01/20/lets-encrypt-6-day-tls-certificates
https://letsencrypt.org/2026/03/11/shorter-certs-certbot

Инструменты и автоматизация:
- cert-manager (релизы, где можно отслеживать поддержку коротких сроков, ACME и т.д.):
https://cert-manager.io/docs/releases/

Хорошие обзоры по общему таймлайну 398 > 47 дней и подготовке:
- Гайд по адаптации к 47‑дневным сертификатам:
https://www.centralnicreseller.com/47-day-ssl-certificates-validity-adaptation-guide-for-businesses
- Обзор сокращения сроков и влияния на процессы:
https://www.eginnovations.com/blog/ssl-tls-certificate-lifetimes-to-reduce-to-47-days

Эпоха "раз в год продлил и забыл" заканчивается.

Владельцам приватных внутренних УЦ в изолированных контурах можно пока расслабиться 😬 - эти правила касаются именно публичных TLS.

#пятница #всратость

Если давно не чувствовали себя неловко - есть проверенный способ взбодриться.

В попытке синхронизировать календари разных систем и отметить свой отпуск (и UPTO), я вместо добавления события в рабочий календарь случайно разослал ВСЕМ в компании приглашение на ивент "Алекс в отпуске".

Классный ивент.
Примите, пожалуйста, и распишитесь.

Я просто сгораю со стыда.😦

#aws #байки

Вторниковая байка.

У AWS SM, если по‑простому, два варианта хранения:
строковый секрет и бинарный.
Строковый в консоли можно редактировать либо как key/value (оно само собирается в JSON), либо как "сырой текст", где ты сам пишешь строку или JSON.

Однажды прилетает ошибка на проде - поды не стартуют.
После деплоя.
Начинаю разбираться - нет кубер‑секрета.
Секрета нет, потому что external secrets не смог подтянуть значение из AWS SM, ругался на какую‑то несовместимость.
Пробую ручной синк - те же ошибки.

Лезу в AWS SM - а там, блять, нет UI‑формы key/value.
Вместо привычной таблички - какой‑то поломанный сырой секрет.
Пришлось ковырять историю, спрашивать разработчиков. Оказалось вот что.

Разработчик добавил новую переменную, значением которой был JSON с множеством вложенностей.
Разумеется, без всякого экранирования, ведь это "никому не надо", а внутри - креды, пароли, спецсимволы😬.
В результате секрет перестал выглядеть как аккуратный JSON‑объект key/value, и консоль перестала показывать его в виде формы - только raw‑строка. Авс конвертнул его из строки в бинарный тип.

External secrets ожидал нормальный JSON, а получил вот эту бинарную кашу,
не смог её распарсить и отказался синхронизировать.
Новые поды без актуального секрета не стартуют, всё висит на старом релизе, который чудом ещё жив.

Ну, короче, разработчик с того времени узнал, что такое экранирование
и почему "просто запихнуть JSON как есть" - это не самое лучшее архитектурное решение.

А я на память, как медальку, сохранил скрин с этой ебалой.

- - -
Воспоминание навеяно обсуждением в кубер‑чате про .NET проблемы.

#troubleshooting #aws #azure #kubernetes #одинденьизжизни

Пришёл алерт ранним утром. Ровно после начала рабочего дня в 10.01.
Чёткий. Конкретный. С именем сервиса, неймспейсом и метрикой.
Не что-то не то с подами, а прям: HighMemoryUsage, payment-service, namespace production, порог 85%, текущее значение 91%.

Открыл дашборд - всё выровнено, таймлайн читается, spike начался ровно в момент последнего деплоя.
Зашёл в ArgoCD, посмотрел diff последнего релиза.
Разработчик увеличил replicas с 3 до 5, но не тронул resources.limits.memory.
Всё сошлось.

Написал разработчику. Он ответил сразу.
Сказал да, моя ошибка и прислал PR через 10 минут.
В PR было описание: что изменил, почему, как проверял локально, какой эффект ожидается.
Коммиты по делу: fix(payment-service): set memory limits and requests after OOM incident.
Не fix, не wip, не asdfgh.
Поправил лимиты, добавил requests заодно.

Пока ждал PR, попросил Cursor посмотреть helm values на предмет других неоптимальных лимитов.
Нашёл два места. Предложил изменения. Ничего лишнего не тронул.

Я заапрувил, ArgoCD задеплоил. Память упала. Алерт закрылся сам.
CI прошёл с первого раза. Без flaky tests. Без "ой, retry нажмите, оно иногда так".

Разработчик после апрува написал в PR: спасибо за ревью, понял, учту.
Следующий его PR пришёл уже с нормальными лимитами. Без напоминания.
В Slack за всё это время никто ничего не написал.

Кстати, на прошлой неделе коллективно договорились не писать @here и @channel в каналах с людьми, если это не реальный прод-инцидент. Все согласились и все соблюдают.

Параллельно пришло письмо от AWS: они самостоятельно обнаружили, что у нас один из инстансов работает в неоптимальном режиме, и предложили конкретный тип на замену - дешевле на 15%.
Написал в саппорт уточнить детали, ответили за полчаса, классные ребята из лондонского офиса, поболтали за жизнь на английском.

Ещё с утра был запланирован автоапдейт AKS - security patch.
Прошёл сам, пока я занимался инцидентом.
Все ноды обновились по очереди, ни одна не упала в NotReady.
API не дёргался. Поды не пересоздавались хаотично.
kubectl get nodes после апдейта вернул всё Ready. С первого раза.
Странно, что я удивляюсь этому, ведь так было всегда, это стабильный и любимый всеми Ажур.

Коллеги наконец перестали спорить что лучше - Windows или Mac.
Все пересели на MacBook. Тихо. Без срачей. Без "но у меня Visual Studio".

Перед обедом написал PM.
Он ответил, что предлагает отменить ежедневный стендап на этой неделе - нет открытых топиков, нет смысла тратить время.

Ещё PM сказал, что руководство приняло решение: гонка за AI - не наша история.
Главное - люди, процессы и спокойная работа.
Никаких срочных внедрений, никакого "а вы уже используете агентов?", никаких OKR про AI-трансформацию до конца квартала.
Ведь главное, чтобы у всех были рабочие места и зарплата вовремя, а не это ваше ИИ.

Весь день занял 40 минут рабочего времени.
Остальное время занимался самообразованием и гладил кота.

Написал постмортем.
Никто не переспрашивал.
Кто-то из команды сам обновил страницу в Notion по итогам инцидента.
Без задачи. Без напоминания. Просто взял и обновил.

NewRelic прислал автоматический отчёт: data ingestion за месяц снизился на 12%. Сам.
Пообедал в 13:00. Целый час, как положено.
Статус в Slack стоял 🍕 Lunch.
Никто не написал. Никто не позвонил. Никто не "быстрый вопрос".

Хороший день.
Может, когда-нибудь так и будет.😀

#guardduty #aws #eks #security #troubleshooting

Guardduty, фишинг. Часть 1 из 2.

Никого не трогаю. Прилетает алёрт от AWS GuardDuty.

Backdoor:EC2/C&CActivity.B!DNS

Продакшн нода в EKS делает DNS-запрос к x****.cn - по базам GuardDuty это известный фишинговый/DGA домен.
Серьёзность - High. В слаке шум, все смотрят на меня.
Блин, почему в мою смену секьюрити инциденты 😬

Окей. Поехали.
Cмотрим что за нода

aws ec2 describe-instances \
  --instance-ids i-0xxxxxxxxxxxxxxxxx \
  --region us-east-1 \
  --query 'Reservations[0].Instances[0].{IP:PrivateIpAddress,State:State.Name,LaunchTime:LaunchTime}'

Нода уже terminated. Karpenter убил её раньше, чем я добрался до расследования.
Живого форензика (digital forensics) нет.
Прекрасное начало.

kubectl get nodes -o wide
# ноды нет

Ладно, живыми данными не поработать, идём в логи.

Cмотрим что вообще крутилось на ноде
Хорошо, что у нас включено всё логирование control plane EKS. Идём в CloudWatch, смотрим логи шедулера - кто и когда был назначен на эту ноду.

aws logs start-query \
  --log-group-name /aws/eks/my-cluster/cluster \
  --start-time $(date -v-83H +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message | filter @logStream like "scheduler" | filter @message like "ip-10-0-25-132" | sort @timestamp asc | limit 50' \
  --region us-east-1

Первая попытка падает с MalformedQueryException. Оказывается, ретеншн у лог группы EKS - 84 часа. Нода жила 4 дня. Часть ранних данных уже недоступна. Запоминаем это на потом.

За те данные, что есть, видим волну деплоя примерно за час до алёрта: новые ReplicaSet хеши, несколько сервисов прокатились роллинг апдейтом. Подозрительно по тайминингу. Ухожу копать туда.

Cмотрим образы, которые пушились незадолго до инцидента

aws ecr describe-images \
  --repository-name my-ecr-repo \
  --region us-east-1 \
  --query 'sort_by(imageDetails, &imagePushedAt)[-10:].[imagePushedAt,imageTags[0],imageDigest]' \
  --output table

Вижу два образа, которые запушились за ~30-60 минут до алёрта GuardDuty. Первая гипотеза: кто-то накатил заражённый образ.

Лезу в git, смотрю коммиты.
Один коммит - это Dependabot, обновил grpc. Проверяю go.sum - стандартные пакеты, нормальные хеши. Второй коммит - двухфайловый вайтспейс-фикс в SQL query builder, strings.TrimSpace в одном файле.

Всё это вообще не то. Red herring, мать ее.

Исключаем DaemonSet

kubectl get daemonsets -A

DaemonSet крутится на всех нодах кластера - их там под 44 штуки. Если бы DaemonSet был заражён, GuardDuty бы полыхал по всем нодам разом. Сработало только на одну. Значит, не DaemonSet.

Базовый образ Dockerfile смотрю - официальный golang bookworm, мультистейдж, всё чисто.

Смотрю дополнительные файндинги GuardDuty

aws guardduty list-findings \
  --detector-id $(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) \
  --finding-criteria '{"Criterion":{"type":{"Eq":["Backdoor:EC2/C&CActivity.B!DNS","Trojan:EC2/DNSDataExfiltration","DefenseEvasion:EC2/UnusualDoHActivity"]}}}' \
  --region us-east-1

Нашлось ещё пара файндингов - не игнорируем, но пока продолжаем копать основное.

Наконец-то заглядываю в логи приложения (когда же я, бл, научусь это смотреть первым 🤡)
Открываю OpenSearch, ищу по домену x********.cn , в индексе EKS-логов.
8 записей. Все - из одного контейнера. Смотрю на таймстемпы:

12:51:19 - PaymentWebhookProcessor: starting to parse note
12:51:19 - PaymentWebhookProcessor: no images found in note
...
13:21:38 - PaymentWebhookProcessor: starting to parse note  <- ВОООТ ОНО
13:21:38 - PaymentWebhookProc...

13:21:38 UTC - точь-в-точь время алёрта GuardDuty.

Попался!

#guardduty #aws #eks #security #troubleshooting

Guardduty, фишинг. Часть 2 из 2.

Что произошло на самом деле
Схема простая до слёз:

Пользователь отправил сообщение с URL -> x*****.cn
        |
Сервис обработки контента внутри кубера получил вебхук(?)
        |
Функция(?) PaymentWebhookProcessor внутри POD-а попыталась резолвить домен
(логика: ищет превью/изображения по URL-ам в тексте)
        |
DNS-запрос к x*****.cn с EKS ноды, на которой запущен под
        |
GuardDuty: ALARM

Никакой малвари. Нода не скомпрометирована. Credentials не угнаны.
Просто сервис резолвит любой домен из пользовательского контента - а юзер прислал фишинговую ссылку.
Фишинг не удался (дополнительно логи смотрел).

Несколько часов расследования, CloudTrail, CloudWatch, ECR history, git blame - ответ лежал в логах приложения и нашёлся бы за 15 минут, если бы я туда полез первым делом.

Что реально плохо и надо починить
Само расследование закончилось словами "малвари нет", но по ходу вскрылись настоящие проблемы 🚬.

- SSRF
PaymentWebhookProcessor резолвит произвольные URL из пользовательского контента без какой-либо валидации.
Это означает, что любой клиент может прислать:
http://169.254.169.254/latest/meta-data/
И сервис спокойно попробует его резолвнуть - прямо с production ноды, у которой есть IAM-роль со повышенными правами (это вообще, бл, отдельный разговор какого рожна нода имела доступ к некоторым AWS ресурсам).

Фикс очевидный - блокировать приватные диапазоны перед любым исходящим запросом:

169.254.0.0/16  (AWS metadata endpoint)
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.0/8

- GuardDuty будет шуметь вечно
Пока сервис зачем-то резолвит пользовательские URL без фильтрации - каждый раз, когда кто-то пришлёт фишинговую ссылку, GuardDuty будет стрелять алёртом. Это шум, который убивает доверие к алёртингу.

Решение: AWS Route 53 Resolver DNS Firewall с managed threat lists.
- AWSManagedDomainsMalwareDomainList
- AWSManagedDomainsAggregateThreatList
Известные вредоносные домены блокируются до DNS-резолва автоматически, без ручных списков.
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html

- URL-резолвинг в основном процессе
Длиннее задача, но правильная: вынести резолвинг URL в изолированный асинхронный воркер с ограниченным egress.
Без доступа во внутреннюю сеть. Без IAM-роли с правами на всё.

Выводы и итоги:
- в логи приложения надо идти первым. Не после нескольких часов инфра-форензики.☔️
- ретеншн CloudWatch-логов для EKS control plane 84 часа - маловато. Нода жила 4 дня, ранние события уже недоступны. Надо поднять. Не критикал, но надо бы.
- сервисы, которые резолвят URL из пользовательского контента, будут встречать фишинг. Это не вопрос если, это вопрос когда. Надо документировать и обрабатывать проактивно, а не разбираться в панике с High severity алёртом.
- SSRF - это не гипотетическая угроза, это прямая дыра в production при текущей архитектуре.
- кто дает права EKS нодам на доступ к AWS ресурсам, то негодяй, нельзя так
- с одной стороны я переживал тогда, что потратил много времени на расследование, копая изначально не туда, с другой стороны рад, ведь без полной картины происходящего я не смог бы понять были ли скомпроментированы креды или нет, был ли хак или нет, а так вроде и пополнил знания
- используйте сервисы AWS, многие из них хорошо помогают в траблшутинге, пусть и стоят денег

False positive закрыт, но работы добавилось.

- - -
В последствии все косяки были закрыты, все Security/AWS бест практисы внедрены.
Все потенциальные известные "дыры" закрыты, PII защищены, даже инвесторы спали спокойно после детальнейшнего постмортема.

#devops #ai #mcp #skills #troubleshooting

MCP, скиллы, ИИ, *уи.

Последние месяцы отказываюсь от MCP серверов.
Прям вот по минимуму оставляю и только от безысходности.
Slack, Linear, Jira, Grafana, VM (Victoria metrics), VL (victoria logs) и так далее.
Им замены мало, без них сложно.

Все MCP для Kubernetes, GitHub, GitLab - все это очень плохо работает в боевых условиях.

Распишу основные минусы из моего опыта:

- трата токенов
Вопреки описанию "да просто мсп сервер ничего не жрет в фоне", это лукавство.
Жрет токены и это видно по логу и трате их по обычным запросам.
Постоянно включать/выключать их я пробовал, но это банально неудобно даже если повесить скиллы/алиасы на это.

- они навайбкожены
Давайте быть честными - больше половины этих серверов это вайбкод вайбкода и работает он ровно так же.
Никаких гарантий, что ИИ агент идет четко по REST API/gRPC, из моей практики они просто хаотично по всем ендпойнтам лезут в надежде найти ответ на вопрос/задачу.

- функционал обрезан. Самый главный и основной минус.
Очень часто натыкался на то, что CLI утилита продукта имеет 99.9% функционала UI, а MCP от силы 60-70% по моим наблюдениям и оценке.
Пример на скриншоте.
Контекст скриншота: обучаю скилл/агента трабшутить упавшие пайплайны гитлаба, и mcp тут не подходит, он даже не может смотреть лог джобы, лол. 😬 Пришлось переписать на glab cli.

- происхождение сомнительное
Большинство MCP‑реализаций сейчас - сторонние, не от официальных вендоров, и часто не строго следуют контракту API или gRPC.
Я пробовал делать "доверительные списки", даже обращался к https://archestra.ai/mcp-catalog, но результат все равно для меня сомнительный.

Мне этого хватило, чтобы со временем отключить почти все MCP сервера там, где есть альтернатива - CLI tool + Skills.

Тут нет речи о том, что MCP - говно.
Тут речь лишь о том, что если есть CLI tool, то MCP не нужен.

Есть glab + TOKEN? MCP GitLab не нужен.
Есть gh + TOKEN? MCP GitHub не нужен.
Есть kubectl + auth? MCP Kubernetes не нужен.
И так далее.

Из плюсов подхода Skills +CLI tool:
- трата меньше токенов
- больший функционал, чем у MCP

Я пробовал заменить MCP VM/VL на "cURL + Skills", это работает и работает отлично, но трата токенов выше примерно на 18-22% по моим графикам и данным. Нерационально, поэтому оставил MCP MV/VL.