#aws #devops #EKS #IRSA

На одном проекте пришла задача избавиться от IAM-кредов в подах и перейти на роли.

Есть три давно созданных EKS-кластера. Я написал Terraform-код: полиси, роль, policy attachment, service account, OIDC и всё остальное. Поправил Helm-чарт, добавив service account. Прокатил изменения по всем кластерам - всё ок.

На DEV я убрал IAM-креды из секретов, чтобы CDK перешёл на роль - всё ок. Сто раз всё проверил: секреты почистил, аппликейшены передеплоил, в AWS-консоли видно, что роль используется, IAM-креды - нет. Удалил IAM для DEV - всё работает. Повторил на STAGE - тоже всё ок.

И тут прод. Удалил креды - и всё рухнуло к чертям. Поды начали использовать роль ноды 🤡, у которой, естественно, нет доступа ко всем ресурсам AWS. Вернул креды, откатил, прод поднял, получил по щщам и начал дебажить.

Сто раз перепроверил Terraform-код - всё идентично. Проверил OIDC, IRSA, роли - всё совпадает, проблем нет. Но почему-то на проде поды не берут нужную роль.

Нырнул в документацию и пошёл шаг за шагом. Это был скучный этап, просто читал, как всё это работает в кишках. Через пару часов упёрся в мутейшн хуки.

Проверил mutatingwebhookconfigurations:
dev

kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
pod-identity-webhook                   

stage

kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
pod-identity-webhook                   

prod

kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
hui

Кто-то (или что-то) когда-то как-то удалил pod-identity-webhook на проде. Как так вышло - история умалчивает, это останется тайной. Жаль только часов дебага, когда я матчил код, роли, OIDC и IRSA, не подозревая, что мутейшн хука просто нет. 🚶‍♀
Что делает этот вебхук? (текст украден из чата кубера):
- Добавляет переменные среды:

AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount
AWS_ROLE_ARN (значение берётся из аннотации к SA)

Добавляет в волумы:

- name: aws-iam-token
  projected:
    defaultMode: 420
    sources:
    - serviceAccountToken:
        audience: sts.amazonaws.com
        expirationSeconds: 86400
        path: token
...
- mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
  name: aws-iam-token
  readOnly: true

И всё. Дальше куб сам выписывает SA-токен с aud: sts.amazonaws.com.

Принял быстрый фикс:
Установил cert-manager (если его не было):

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml

Склонировал и развернул:

git clone https://github.com/aws/amazon-eks-pod-identity-webhook
cd amazon-eks-pod-identity-webhook
make cluster-up IMAGE=amazon/amazon-eks-pod-identity-webhook:latest

Проверил логи:

kubectl logs -n default -l app=pod-identity-webhook

Запустил тест:

kubectl run irsa-test --image=amazon/aws-cli -n production --overrides='{"spec":{"serviceAccountName":"new-sa"}}' --command -- sh -c "aws sts get-caller-identity && sleep 3600"

Получил:

{
    "UserId": "54252523:botocore-session-2345452354",
    "Account": "2345452345",
    "Arn": "arn:aws:sts::234534524:assumed-role/expected-new-role/botocore-session-345235"
}

Ура, теперь поды используют новую роль. Убил тестовый под. Удалил IAM-креды, накатил снова - всё ок.
Задача решена.🎉

.....
Прошло пару дней.
.....

Сижу, значит, пишу этот текст-заметку, пока не забыл, и задумался: неужели такое возможно в 2025? Зачем? Зачем, мистер Андерсон, вообще руками что-то ставить в кластер, kubectl apply -f??

Читаю за утренним кофе документацию, пока жена не видит:
- https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
- https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html
Дошёл до:
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_pod_identity_association
.
..
...
Прочитал, промолчал, набычился, посмотрел на пол, закатил глаза, надел kubectl apply -f клоунский нос 🤡 и отправил пост в телеграм.

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

Буквально на пару дней был недоступен для работы.
В это время разработчикам срочно надо было для тестов фичи создать 3 бакета в 3 регионах:
us-east-1(default), us-east-2, ca-central-1.
Вообще для этого есть модуль, просто регион указать, однако они сделали по своему и клик-опсом.
Накатили, проверили, сдали бизнес-заказчику, написали всем "фича работает и проверена на бакетах в 3 регионах!".
Запилили мне таску "добавить бакеты импортом в терраформ.

Возвращаюсь на работу - вижу это 😀

#terraform #aws

Самая нелюбимая часть работы - terraform hell dependency и AnyCloudProvider(в данном примере AWS) deprecated resources/versions.
Вишенка на торте - вкупе с публичными модулями.

То есть "что-то скоро перестанет работать - обнови версию".
Просто обнови и всё! 😀

Простой пример: прилетает письмо от AWS "скоро python9 станет депрекейтед в AWS"
Никаких возражений, я полностью согласен с такой позицией. 100% верно.
Пилим таску "обновить версию рантайма везде", иначе через 180 дней превратимся в тыкву.

Проверяем есть ли у нас лямбды 3.8/3.9.

aws lambda list-functions --region us-east-1 --output text --query "Functions[?Runtime=='python3.8'].FunctionArn"
aws lambda list-functions --region us-east-1 --output text --query "Functions[?Runtime=='python3.9'].FunctionArn"

Увы, есть. Находим один аж с 3.8. С него и начнём.

Казалось бы - в чём сложность? Версию апдейтни.
Попытка обновить версию самого модуля - получаю ошибку, что террраформ версии 1.5.3 не подходит, тут нужно минимум 1.5.7. Просто так указать ему версию рантайма не прокатывает - он не в курсе про такой параметр в этой старой версии.
Хорошо, везде обновляем терраформ на 1.5.7, но теперь ругается на провайдеры, terraform/aws. Их тоже надо обновить.
Обновляем и их повсеместно. Прогоняем план - последовательно находим 4 бага - в github issues, обновляем раз за разом разные версии, вроде прошли к какой-то, в котором багов нет. Появляются даже какие-то костыли с lifecycle.
В двадцатый раз уже terraform plan - появились обязательные поля у части ресурсов, а они не указаны.
И так по кругу. Хистори показало печаль 😭

history | tail -n 200 | grep plan | wc -l
59

И вот что тут делать?
- либо дальше повышать версию за версией, добавлять/убавлять параметры, чтобы стейт с кодом был идентичным, пока это говно не заработает
- сделать роллбек всех сделанных изменений кода с версиями, повесить техдолг

Потрачено уже немалое количество времени и принимаю решение - делаю роллбек.
Нужен рабочий и код и стейт. А роллбек ничего и не дал. 🚶‍♀
В лямбде версия рантайма уже 3.12 и откатить обратно к 3.8 не даёт - нет даже такого поля(а скоро и не станет 3.9).

Да что же такое. Значит ни первое и ни второе решение, предложенное выше.
В итоге просто иду на страницу модуля старой версии, копирую все ресурсы as is, пишу свой модуль и свои версии зависимостей. Убираю несколько лишних ресурсов и прав к ним.
Запускаю лямбду - ошибка питон кода, ведь он был написан для 3.8, а у меня 3.12.
Переписываю питон скрипт, проверка - всё работает.
Обновляю сразу все зависимости до последнего актуального, чтобы оно дольше проработало.
Выпиливаю публичный модуль, документирую свой модуль, план, фиксирую версии, терраформ апплай - всё работает.

Вот так, попытка "просто сделать апдейт версии питон рантайм лямбды" вышло в 5 часов абсолютно глупой работы. Итог плохой:
- мне он не нравится
- технический долг немного вырос
Из хорошего
- выпили ещё один сомнительный модуль, который своими зависимостями ломает вообще всё к херам.
- не поломали код и стейт
- обновили все лямбды до 3.12 (не только от старого паблик модуля, а везде)

Мне кажется, тут нет правых, виноватых. Хороших и плохих решений.
Эта ситуация возникала не раз, уж слишком у нас много зависимостей в нашем коде, инфраструктуре и работе. Особенно сторонних модулях.
Можно сколь угодно обвинять "а чо ты раньше не обновился?", "а чо ты на 1.5.3 сидишь как сыч?" и многое другое.
Не хватает ресурсов, чтобы всё держать в обновлённом состоянии. Увы.

#aws #smallindiecompany #ui #🐒

ALRIGHT AWS, ALRIGHT, I GET IT

#troubleshooting #aws #ssh #retool #paranoia #linux

Есть такая штука, называется retool https://retool.com/
Какая-то платформа для менеджеров, я ей не пользовался никогда в бизнес уровне.
В UI интерфейсе мышкой подключаются resource и на их базе могут строятся какие-то таблички, панели и прочая не интересная мне информация для менеджеров и сейлзов(наверное).
Resources чаще всего это база данных. Например MySQL или PostgreSQL. У retool тысячи их для любых интеграций.
Это всё, что надо знать для начала, идём дальше.

В основном Retool из интернета подключается к вашим ресурсам либо напрямую по hostname, либо к AWS через IAM credentials, либо через SSH bastion host.
Первый случай я не знаю для кого, у меня пока не было опыта публичных БД, второй способ мне не нравится, да и не пройти с ним SOC2 аудит, так что у нас только третий вариант - через ssh tunnel.

У них есть вполне годный гайд https://docs.retool.com/data-sources/guides/connections/ssh-tunnels, который подойдёт для 99% случаев.
Создаётся пользователь на бастион хосте(например через ansible или руками), добавляется их ssh public key, раскидываются права - всё готово. В общем всё по инструкции.
При подключении ресурса вы в UI указываете ваш bastion хост, порт и прожимаете test connection.
Если всё ок- ошибки нет. Не ок - ошибка.
Ошибка чаще всего дурацкая, потому что открывается какой-то аналог developer tool и показывает длинный стактрейс.

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

PubkeyAcceptedKeyTypes +ssh-rsa

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

resource "aws_security_group" "bastion" {
...
  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"
    # https://docs.retool.com/data-sources/reference/ip-allowlist-cloud-orgs
    # retool ip ranges only
    # tfsec:ignore:aws-ec2-no-public-ingress-sgr
    cidr_blocks = [
      "35.90.103.132/30",
      "44.208.168.68/30",
      "3.77.79.248/30"
    ]
    description = "SSH access from allowed IP ranges"
  }
...

Потом добавились секюрити группы по MySQL/PostgreSQL типа

resource "aws_security_group_rule" "this" {
  type              = "ingress"
  from_port         = 5432
  to_port           = 5432
  protocol          = "tcp"
  cidr_blocks       = ["*********"]
  security_group_id = aws_security_group.rds.id
  description       = "Allow PostgreSQL access from ***** VPC"
}

Так же сразу сделал отдельного пользователя в БД с чётко обрезанными правами.
Делал что-то ещё, и в целом был удовлетворён, что тварь какая-то ходит в мои сети.

Прошло много лет.

Ко мне приходят ребята инженеры, говорят хотят добавить новую БД для retool.
Уже подключена монга, mysql и всякое, а теперь надо и PostgreSQL.
Ок, говорю, ну там всё уже настроено - все ssh ключи, секьюрити группы и прочее - всё должно работать - другие то ресурсы(БД) работает до сих пор.
Берите креды и сами настраиваете, мы же договорились, что не должно быть боттлнека -девопса.
Они высылают скрин, что ошибка подключения. Я само собой не верю (бл, когда я научусь думать, что другие люди не глупее меня 🐒, баран самоуверенный).
Иду сам в retool, копирую все креды, создаю ресурс, но у меня тоже ошибка.
Извиняюсь перед ребятами, пилю тикет, начинаю разбираться.😭

#aws #azure #gcp #kubernetes

Допустим вы сменили место работы.
На новом месте GCP, Azure, AWS. Миллионы куберов.
Разные тенанты, разные сабскрипшны, разные профили, разные аккаунты, разные регионы.

Ваше железо с нуля, в нём пока нет ничего (а зачем старое со старых работ тащить?)
Надо установить утилиты, Надо обновить кубконфиг.
Чтобы видеть сразу всё и сразу (из доступного по правам).

Первым делом ставим asdf.
https://github.com/asdf-vm/asdf/releases
Затем добавляем тулзы.

cat ~/.tool-versions

kubelogin 0.1.4
helm 3.17.0
dive 0.12.0
sops 3.9.4
terragrunt 0.54.15
terraform 1.5.3
kubectl 1.29.0
awscli 2.31.6
aws-sso-cli 2.0.3
kubectx 0.9.5
eksctl 0.215.0
azure-cli 2.77.0
jq 1.8.1

Апплаим (у меня это алиас asdfu)

cut -d' ' -f1 ~/.tool-versions | xargs -I{} asdf plugin add {} && asdf install

Теперь у нас есть все необходимые утилиты

Затем конфигурируем один раз профили(если есть).

aws configure sso 
# или
aws configure sso --profile profilename
az login

Теперь нам надо один раз залогиниться в ажур и амазон.
Где-то достаточно
az login и aws sso login
где-то разово надо попрыгать по профилям

aws sso login --profile profilename

Мы залогинились во все тенанты, все подписки, все аккаунты.
Как теперь в автоматике собрать все кубконфиги?
На помощь нам приходит любимый bash ❤️.

AWS (пример)

account_id=$(aws sts get-caller-identity --query Account --output text)
eksctl get cluster --all-regions -o json | jq -r '.[] | [.Name, .Region] | @tsv' | while read -r name region; do
  aws eks update-kubeconfig \
    --name "$name" \
    --region "$region" \
    --alias "${account_id}_${name}-${region}"
done

Azure (пример)

origin_context=$(kubectl config current-context)
original_subscription_info=$(az account show --query '{id:id, name:name}' --output json)
original_subscription_id=$(echo "$original_subscription_info" | jq -r '.id')

subscriptions=$(az account list --query "[].id" --output tsv)
for subscription in $subscriptions; do
    az account set --subscription "$subscription"
    clusters=$(az aks list --query "[].{name:name, resourceGroup:resourceGroup}" --output json)
    for cluster in $(echo "$clusters" | jq -c '.[]'); do
        cluster_name=$(echo "$cluster" | jq -r '.name')
        resource_group=$(echo "$cluster" | jq -r '.resourceGroup')
        az aks get-credentials \
            --resource-group "$resource_group" \
            --name "$cluster_name" \
            --overwrite-existing \
            --context "${subscription}_${cluster_name}"
        kubelogin convert-kubeconfig -l azurecli
    done
done
kubectl config use-context "$origin_context"
az account set --subscription "$original_subscription_id"

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

# AWS
<account_id>_<cluster_name>-<region>
# Azure
<subscription_id>_<cluster_name>-<region>

Алиасы каждый пилит сам под себя - как кому удобнее.
Можно даже добавлять суффикс, что за кластера

# AWS
eks-<account_id>_<cluster_name>-<region>
# Azure
aks-<subscription_id>_<cluster_name>-<region>

Очевидно, что если аккаунт один, подписка одна и регион один - сложный нейминг не нужен.

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

Вводим kubectx, видим огромный список всего.

> kubectx

aks-98765-98765-98765_stage-fake-centralus
aks-54321-54321-54321_dev-fake-eastus2
aks-12345-12345-12345_uat-fake-germanywestcentral
eks-123456789_dev-project1-us-east-1
eks-123456789_stage-project2-us-east-2
...

Cвичимся в нужное и поехали работать.

* в условиях разных SSO и корпоративных политик некоторые способы могут отличаться. Это лишь общий паттерн.

А доступ в GCP вам так и не дали 😀

#aws #opensearch #elasticsearch

Однажды надо было обновить ElasticSearch в амазоне.
По историческим причинам была старая версия эластиксёрч.
Пришло какое-то уведомление "через какое-то время будет расширенная версия саппорта за деньги, обновляйся или плати", а это всегда страшно.
Никто не хочет платить за просранные сроки.

Было три классических окружений(dev, stage, prod), все одинаковые по конфигу терраформ модуля, но отличающиеся по размеру стораджа, типу инстансов, шардам и количеству инстансов, на деве вроде был всего один.

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

resource "aws_elasticsearch_domain" "elasticsearch"

на

resource "aws_opensearch_domain" "opensearch"

- выполнить удаление старого ресурса

terraform state rm aws_elasticsearch_domain.elasticsearch

- добавить новый ресурс импортом

terraform import aws_opensearch_domain.opensearch %domainname%

- прогнать терраформ план и поправить, где чего упущено (ну там новые названия переменных для .tfvars файла и типа того, не помню уже).
- проверить все дашборды в графане(есть ли метрики и не поменялись ли они), поправить если надо
- проверить все метрики для алертов и алерты, поправить если надо
- коммит и отправить MR

Не сложно, не правда ли?
Пока без каких проблем.

Однако в процессе миграции кто-то решил "а давайте ещё и SSO включим! Ну всё равно же апдейт!" 🤩.
SSO так SSO, правила диктуют боссы и стейкхолдеры.
К текущему плану добавляем новый ресурс нечто типа (могут быть опечатки, пишу на память и примерам)

resource "aws_opensearch_domain" "opensearch"
...
  advanced_security_options {
    enabled                        = true
    internal_user_database_enabled = true
    master_user_options {
...
  }

и

resource "aws_opensearch_domain_saml_options" "saml"
...

- ну ещё там добавились всякие политики, роли и так далее. Я думаю это и так очевидно. Перечислять не буду.
- со стороны коллектора логов (Vector/VMlogs/fluentbit/Fluentd etc - выбор у каждого свой) добавилась ещё и авторизация - если УЖЕ включили SAML/SSO на OpenSearch, то для банальной отправки логов в хранилище будет авторизация.
- добавить 3 Azure enterprise application - на каждый из энвов, ведь Reply URL (Assertion Consumer Service URL) везде разный. Если был бы один опенсёрч на все энвы - был бы один аппликейшн.
- коммит и отправить MR, получить аппрув

Внесли в код, начали апплаить - а всё работает!
Коллектор логов шуршит, собирает логи, асьюмит роль, монтирует токен, цепляется к опенсёрчу, проходит авторизацию, аутентификацию и успешно делает PUT логов.
Пользователи отлично заходят на OpenSearch UI через SSO и всё работает.
На всё ушло около 4 часов чтения доков и вроде полутора-двух часов для апплая и отладки.

Ок, идём к Stage окружение, там повторяем примерно всё, что написано выше, правим мелкие недочёты если есть.
Почти не было кода, лишь просто выполнять команды в порядке, описанном в тикете.
На всё ушло вроде меньше 2 часов.
Всё так же работает.