Недавно мы шаблонизировали всю инфраструктуру AWS с использованием облачной информации. И я бы держал роли и политики IAM ближе к стеку приложений, а не в одном шаблоне. Я постараюсь объяснить мои причины.
У нас есть отдельная учетная запись AWS для каждого TeamEnv.
What is a TeamEnv?
Если у нас есть 3 команды, например А, В и С.
И 3 среды, например Dev, Staging и Prod.
Тогда у нас есть 9 TeamEnv: A-Dev, A-Staging, A-Prod и так далее для всех остальных команд. Итак, всего у нас 9 аккаунтов AWS. Это делается для обеспечения подотчетности, а также прозрачности ресурсов.
И вот как мы это сделали. Мы разделили стеки на следующие категории:
Общие стеки облачной информации AWS:
Это стеки, которые будут общими для всех команд и их окружения:
Стек учетной записи суб-пользователя IAM - этот стек создает суб-учетную запись IAM с правами администратора.
Общий стек VPC - Этот стек создает VPC и его компоненты в соответствии со стандартами компании.
Стек пиринга VPC - Этот стек предназначен для пиринга VPC.
Стек пиринговых ролей VPC - этот стек создает роль VPC, необходимую для пиринга.
Стеки, специфичные для команды:
Стек ELB - Он зависит от универсального стека VPC и импортирует из него экспортированные значения, например VPCId .
Специфичный для службы стек - Он зависит от универсального стека VPC и стека ELB и импортирует различные экспортируемые значения. У нас есть один стек для каждого микросервиса, и он состоит из всего, что нужно для перевода сервиса в состояние готовности. Включает в себя s3 корзины, SQS, InstanceRole и т. Д.
Именно здесь мы управляем ролями и политиками IAM. Проще управлять и проверять.
Однако, оглядываясь назад, я бы сохранил отдельный стек для политик IAM, которые обычно используются и на которые ссылаются в других ролях, чтобы избежать дублирования встроенных политик.