How should a solutions architect grant this access to the vendor?
Create a IAM role in the company’s account to delegate access to the vendor’s IAM role. Attach the appropriate IAM policies to the role for the permissions that the vendor requires.
Create an IAM user in the company’s account with a password that meets the password complexity requirements. Attach the appropriate IAM policies to the user for the permissions that the vendor requires.
Create an IAM group in the company’s account. Add the tool’s IAM user from the vendor account to the group for the permissions that the vendor requires.
Create a new identity provider by choosing ג€AWS accountג€ as the provider type in the IAM console. Supply the vendor’s AWS account ID and user name. Attach the appropriate IAM policies to the new provider for the permissions that the vendor requires.
Explanations:
Creating an IAM role in the company’s account and delegating access to the vendor’s IAM role is a best practice for cross-account access. This allows the vendor’s automated tool to assume the role in the company’s account with the necessary permissions without directly granting IAM user access to the company’s resources.
Creating an IAM user in the company’s account would require managing individual user credentials, which is less secure and scalable compared to using IAM roles. IAM users are typically used for individual accounts, not for granting cross-account access.
IAM groups are used for managing permissions for users within the same AWS account, but the vendor is in a different AWS account. Adding the vendor’s IAM user to a group in the company’s account is not possible and would not grant cross-account access.
While creating an identity provider (such as a federated identity provider) is a valid way to grant access, it is not the simplest or most recommended method for this scenario. Using an IAM role to allow cross-account access is more straightforward and secure than configuring an identity provider.