Which of the following solutions would provide the MOST scalable solution?
Create dedicated IAM users within each AWS account that employees can assume though federation based upon group membership in their existing identity provider.
Use a centralized account with IAM roles that employees can assume through federation with their existing identity provider. Use cross-account roles to allow the federated users to assume their target role in the resource accounts.
Configure the AWS Security Token Service to use Kerberos tokens so that users can use their existing corporate user names and passwords to access AWS resources directly.
Configure the IAM trust policies within each account’s role to set up a trust back to the corporation’s existing identity provider, allowing users to assume the role based off their SAML token.
Explanations:
Creating dedicated IAM users in each account is not scalable because managing individual IAM users across multiple accounts increases administrative overhead and complexity. This approach also does not leverage the benefits of federated identity, which allows centralized management of users.
Using a centralized account with IAM roles allows for a scalable solution by leveraging federation with an existing identity provider. Employees can assume roles across multiple accounts, which simplifies access management and reduces the need for separate IAM users in each account. This approach facilitates easier permissions management and enhances security through role-based access.
Configuring AWS Security Token Service to use Kerberos tokens is not the most scalable approach. While it allows existing usernames and passwords to be used, it introduces complexity with token management and does not centralize access control effectively across multiple AWS accounts. This method also ties users to specific authentication mechanisms that may not be optimal for all scenarios.
Configuring IAM trust policies for each account to allow SAML token-based access is less scalable compared to using centralized roles. While this approach provides federated access, it still requires configuration in each account, making it more cumbersome to manage as the number of accounts grows. It lacks the centralized role assumption capabilities that enhance scalability.