Как обеспечить доступ команды разработчиков к AWS?

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

1. Один вход на всех, но не как в общественный сортир. Вместо того чтобы плодить логины-пароли, которые потом на стикерах по мониторам висят, я подключаю AWS IAM Identity Center (это тот самый SSO, который переименовали, ёпта). Интеграция с корпоративной Active Directory или Okta. Человек тыкает одну кнопку, и ему на время сессии даются ключи — и в консоль, и в CLI. Удобно, блядь, и не нужно эти ключи в ~/.aws/credentials хоронить, где их любой скрипт-сосалка может утянуть.

2. Раздача прав — это вам не конфетки из вазы тырить. Тут принцип простой: давать ровно столько, чтобы работу сделать, и ни капли больше. Иначе будет пиздец.

• Группы, а не личности. Я не бегаю за каждым Петей и Ваней. Создаю группы: Developers, DevOps, ReadOnly. Кидаю человека в группу — и всё, права у него уже есть. Чисто и понятно.
• Теги — наше всё. Вместо того чтобы разрешать ec2:* на весь аккаунт (это пиздец какой уровень доверия, ноль ебать), я привязываю политики к тегам. Хочешь ковырять инстансы только в дев-среде? Получай политику, которая работает только если у инстанса тег Environment=Development. Вот, смотри, как это выглядит:

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": "ec2:*",
              "Resource": "*",
              "Condition": {
                  "StringEquals": {
                      "ec2:ResourceTag/Environment": "Development"
                  }
              }
          }
      ]
  }

  Сделал что-то в продакшене? Получи, хитрая жопа, AccessDenied и иди переделывай.

• Для железяк — свои роли. Jenkins, GitLab Runner или какое-нибудь приложение на EC2 — им я не статические ключи выписываю (это прямой путь на стену позора, когда их скомпрометируют). Для них создаю IAM-роли, которые они могут принять. Безопасно и элегантно.

3. Многофакторка — обязательно. Без вариантов. Доступ в консоль? Без MFA — ни шагу. Это даже не обсуждается, ёбать колотить. Для CLI, когда логинишься через тот же Identity Center, MFA тоже запрашивается. Да, иногда лень, но это та цена, которая спасает от волнения ебать, когда пытаются зайти с незнакомого IP.

4. За всеми следим, как в лучшем доме. Включаю AWS CloudTrail абсолютно во всех регионах. Чтобы все API-вызовы, все DeleteVolume и TerminateInstances летели в центральное S3 или CloudWatch Logs. Потому что когда что-то пойдёт не так (а оно пойдёт), нужно не орать «кто это сделал?!», а открыть логи и за пять минут найти этого распиздая. Для аудита и спокойного сна — must have.

5. Если аккаунтов больше одного — организуем бардак. Когда команд и сред несколько, тащить всё в одном аккаунте — это манда с ушами. Использую AWS Organizations. Создаю отдельные аккаунты под продакшен, тесты, разработку. А через Organizations централизованно управляю доступом (те самые SCP — Service Control Policies, которые могут запретить всему аккаунту, например, регионы за пределами EU создавать) и свожу все счета в одну кучу. И тот же Identity Center работает на все эти аккаунты — вошёл один раз и переключаешься между ними. Красота, ядрёна вошь.

Вот такой, блядь, подход. Кажется, овердохуища правил, но зато потом не приходится тушить пожар, потому что какой-то стажёр по ошибке всю базу RDS прибил.