AWS Notes

Всех приветствуем! 🔥 Выпущена 0.29.1 версия платформы для изучения SRE! 🔥 GitHub 📌 Что нового: - добавлена поддержка 1.35 k8s - добавлена статья Vibe Coding → Spec-Driven: How AI Development Found an Engineering Approach - добавлена статья From Spot.io to Karpenter: Node Management Migration Experience in Kubernetes - добавлена лаба 01 Istio.Installing Istio - добавлена лаба 02 Istio.Dark Launch окружения. - обновлён список полезных ссылок. 🧪 Доступные пробные экзамены: CKA CKAD CKS ICA KCNA KCSA LFCS 🧪 Доступные лабораторные работы Скрипты и видео с решениями экзаменов: документация ping-pong сервера Отличного настроения и пусть ваш прод живёт без падений!

It might become an alternative to LocalStack Floci - Light, fluffy, and always free - AWS Local Emulator https://github.com/hectorvent/floci

Крупнейший взлом 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 в последнее время — перепроверить и в любом случае лучше обновить секреты.

Распределённое БЕСПЛАТНОЕ хранилище данных на CloudShell Кто вдруг не знает, CloudShell даёт бесплатно не только запускать, но и хранить 1 ГБ информации на дисках. Да, 1 ГБ это не шибко много. НО. В каждом аккаунте и в каждом регионе. Нонче это 25 регионов. Итого, нужно всего 4 аккаунта на 100 ГБ места. НАХАЛЯВУ! https://github.com/dan-v/cloudshell-store Built-in Disaster Recovery: информация максимально устойчива к падению чего-то угодно, ибо распределена по всем регионам сразу. P.S. DNS on Route53 проехали. Переходим на NFS on CloudShell. 😁

https://aws.amazon.com/blogs/aws/twenty-years-of-amazon-s3-and-building-whats-next/ 😉

Не надо раздражаться! #пятничное

Air-gapped Firewall #friday

Hey guys~ ☀️ FYI: There are upcoming changes. Starting on March 25, 2026, you will receive all AWS invoices from “invoicing@aws.com”. FYA: If you have automated rules configured to process invoice emails, you need to update the email address.

Barev, people jan! 🚩 We are teaming up with the AWS Skills Center to bring you a completely FREE AWS AI Practitioner Certification Prep Course this April led by the mentors from AWS! Why this certification? It is currently the "must-have" foundational tech credential! It proves you actually know how to build with Generative AI securely and responsibly. And our favorite part? The official mentor leading the sessions directly from AWS is Armenian! 🇦🇲🫶🏻 Before we lock in the final schedule with AWS (either 1 or 2 times a week), we need to gather exact numbers for our private cohort. 📌 The Quick Details: When: Starting in April at 6:00 PM Yerevan time Duration: 6 sessions total (5 content + 1 exam prep), ~2.5 hours each Language: English You get: Free materials, live instructor demos, hands-on practical sessions, and a certificate of completion. 🛑 AWS strictly does NOT allow recordings. You must be able to join us live! If you are 100% ready to commit and level up your AI skills, please fill out the registration form by this Friday, March 13th! 🔗 https://forms.gle/SdHNtS6ozggM2mWA8 AI skills are the highest-paying premium in the market right now, so don’t miss giving your professional profile a massive boost!

Поздравляю нового AWS Community Builder-а! 🎉

AI-агенты атакуют AI-агентов AI-агент hackerbot-claw, представляясь исследовательским агентом на базе claude-opus-4-5, в течении недели сканировал популярные open-source проекты. Находил ошибки в GitHub Actions и эксплуатировал их для RCE. https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation Наиболее крупный пострадавший — проект Trivy, у которого украли PAT. В результате родную репу перезаписали пустой и удалили все релизы за несколько лет. Другие известные пострадавшие: - https://github.com/microsoft/ai-discovery-agent — инъекция через хитрое имя ветки. - https://github.com/DataDog/datadog-iac-scanner — инъекция shell-команд через имена файлов. - https://github.com/avelino/awesome-go — кража GITHUB_TOKEN с правами на запись через подмену Go-скрипта. - https://github.com/ambient-code/platform — prompt injection, нацеленная на AI-ревьюера (Claude), которая, правда, была успешно самим Claude и заблокирована. - https://github.com/project-akri/akri — инъекция скрипта через /version minor комментарий. - https://github.com/RustPython/RustPython — инъекция Base64-пейлоада через имя ветки. Как защититься: 1. Если пайплайн (особенно с AI-агентами) должен чекаутить код из форка — использовать только pull_request. Если нужен pull_request_target, НЕ делайть чекаут кода из PR-ветки. 2. Permissions - только read и write только там, где реально нужно. 3. Не передавайте неэкранированные переменные типа ${{ github.event.pull_request.head.ref }} напрямую в run: блоки bash-скриптов — используйте environment variables. Такие времена — теперь агенты ломают агентов.

Настоящий мульти-аккаунт подход в действии: https://aws.amazon.com/blogs/architecture/6000-aws-accounts-three-people-one-platform-lessons-learned/ Для каждого клиента создаётся отдельный AWS аккаунт. Что даёт максимальную изоляцию (безопасность), простой подсчёт затрат (цена). #multi_account_strategy

↘️ ...was impacted by objects that struck the data center... ▪️ me-south-1 (Bahrain) — "localized power issue" ▪️ me-central-1 (UAE) — "localized power issue" https://health.console.aws.amazon.com/health/home#/account/dashboard/open-issues

Как AI меняет роль архитектора - Чем занимается архитектор: список активностей – Технические вопросы и AI: 90% замена – Архитектура: контекст важнее технических знаний – Билдинг: от 2 недель до 6 часов – Обучение: как AI меняет процесс – Изменение ролей – Эксперт-дженералист: как оставаться на коне YouTube: https://www.youtube.com/watch?v=bm_S0kFKC0E А также: 🔹 Podbean 🔹 Apple Podcast 🔹 Яндекс.Музыка 🔹 Spotify 🔹 RSS

Too often, Architecture diagrams become outdated the moment they’re saved, leading to a growing documentation debt. In my latest article, I explore how AWS Kiro and MCP (Model Context Protocol) are automating this process. 🔗 Read the practical guide here (Armenian, can be easily translated to English with browser extension): https://shorturl.at/DyA29

🤖 Агенты зажигают. 🔥

#aws #rds #troubleshooting Приходят как-то коллеги, говорят - нет прав включить Enhanced Logging на RDS Proxy. Для дебага очень надо на пару часов. Ок, смотрю политику, а там rds:* на Resource = "*". Говорю - всё есть, всё должно работать. Хоть дропайте всё к херам (stage account). Возвращаются - нет, всё равно не работает. Проверяю глазами ещё раз полиси. Да вроде всё ок. Говорю сделайте релогин и попробуйте ещё, все права есть. Снова возвращаются, сделав релогин. Говорят "включаем, а оно не включается". Делаю невозмутимое лицо, хотя внутри уже кривлюсь как хурма: описание проблемы уровня "включаем, а не включается, ошибок нет" звучит слишком уныло, чтобы воспринимать его всерьёз. Прошу объяснить подробнее. Мне показывают по шагам: - зашли в консоль - зашли в RDS - нашли нужный proxy - нажали Edit/Modify (я не помню название кнопки) - поставили галочку "Activate enhanced logging" - нажали "Modify proxy" - видят надпись "Modifying proxy ..." - видят зелёный баннер "Successfully modified proxy ..." - выходят, заходят снова - галочки нет Нигде ни одной ошибки. Всё выглядит как успех. Но изменение не применяется. В ивентах пусто. Повторяю сам под своим admin пермишнсетом - у меня работает, галочка стоит. В ивентах изменения появились. Ладно, добавляю себя временно в эту группу и начинаю воспроизводить. Захожу под их пермишнсетом, повторяю их действия. Та же история - "Successfully modified", а галочка не стоит. Думаю что не так. Выхожу из SSO, захожу снова - галочки нет. Сбрасываю кеш браузера - галочки нет. Пробую другой браузер - галочки нет. Смотрю в developer tools в браузере - никаких ошибок, никаких 403, всё 200. Смотрю в сам UI консоли - ни единого красного баннера, ни единого намёка на проблему. Само собой инкогнито мод браузера не помог. Ивентов нет. Потратил на это ещё чуть времени, пока до меня наконец не дошло. Дурачок, - думаю я, - а CloudTrail-то ты проверил? Иду в CloudTrail, фильтрую по ModifyDBProxy. Нахожу событие. И там:

"errorCode": "AccessDenied",
"errorMessage": "User: ... is not authorized to perform: iam:PassRole
on resource: arn:aws:iam::ACCOUNT_ID:role/rds-proxy-wanker
because no identity-based policy allows the iam:PassRole action"

Вот оно. AWS при вызове ModifyDBProxy передаёт IAM роль прокси в Secrets Manager. Для этого нужно право передать (PassRole) именно эту роль. rds:* тут ни при чём - это отдельное действие на отдельный ресурс. В политике группы iam:PassRole был разрешён только для одной конкретной роли. Про rds-proxy-* никто не подумал. Добавляем в политику:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::ACCOUNT_ID:role/rds-proxy-*"
}

Применяем, перелогиниваемся. Галочка встаёт и остаётся стоять. Ивенты пишутся. Итоги: - "Successfully modified" в AWS консоли не гарантирует, что изменение применилось 🥲 - AccessDenied может прилетать не на само действие, а на зависимое - в данном случае на iam:PassRole - Консоль эту ошибку не показывает совсем. Молча глотает. Никакого красного баннера. Никаких ошибок. Никаких ивентов. 😎 - CloudTrail - первое место, куда надо смотреть, когда "всё работает, но не работает" - rds:* не равно "всё для RDS". Некоторые операции тащат за собой зависимости на другие сервисы - нехер снова кривить свою морду, коллеги всё же солнышки-зайчики и правы, даже если пояснение проблемы тупорылое