Я хочу разделить ресурсы AWS для мультитенантного SaaS на отдельные учетные записи в Организации AWS.
- У меня есть несколько подразделений, разделенных по функциям, например, журналы, аудит, вычисления. У меня будут SCP, связанные с каждой OU.
- У каждого арендатора будет учетная запись в каждой OU, что означает, что при добавлении новых арендаторов каждая учетная запись будет наследовать соответствующий SCP в этой OU.
Чтобы позволить разработчикам построить платформу и иметь возможность отладки работающей системы, я хочу использовать подход типа концентратора и спицы для контроля доступа с использованием федеративного IdP, аналогичный описанному здесь: https://segment.com/blog/secure-access-to-100-aws-accounts/.
В частности, у меня будет учетная запись identity, которая будет связана с Okta. Пользователи будут проходить аутентификацию в этой учетной записи, а затем использовать sts:assume-role для перехода к ролям в других учетных записях. Обратите внимание, что мне нужна отдельная учетная запись identity, и пользователи не должны проходить проверку подлинности для учетной записи master в организации (таким образом, в организации у нас есть учетные записи master и identity, а также подразделения с каждой соответствующей учетной записью). .
Чтобы программно создать нового арендатора, мне нужно создать учетные записи арендатора и поместить их в правильное подразделение, и, следовательно, это необходимо сделать в учетной записи master. Я могу сделать это, создав роль в учетной записи master и предложив разработчикам взять на себя эту роль из учетной записи identity.
Как создать роли в новых учетных записях, которые разработчики могут принять из identity учетная запись? Учетные записи участников имеют роль, называемую OrganizationAccountAccessRole, автоматически создаваемую (см. здесь, для получения подробной информации ), но она настроена так, чтобы быть доступной только из основной учетной записи, и она обеспечивает доступ к всему в этомучетная запись. Как я могу позволить разработчику в учетной записи identity программно создавать новые учетные записи и роли в них без предоставления таких всесторонних разрешений (у них должно быть не больше разрешений для выполнения этой задачи, чем необходимо). Я не думаю, что могу взять на себя роль в учетной записи master из учетной записи identity, а затем принять на себя роль в третьей учетной записи?
РЕДАКТИРОВАТЬ: меня действительно интересуют только ответы на этот адресшаги / конфигурация, необходимые для достижения решения, которое я описываю.