To understand the meaning of this, you need to understand some of the details of how the IAM roles work.
The IAM role is similar to the user in its structure, but instead of accessing a fixed set of credentials, it is used instead, assuming the role, which means requesting and receiving temporary credentials APIs that allow you to take actions with privileges granted to this role .
The sts:AssumeRole is the means by which such temporary credentials are obtained. To use it, the user or application calls this API using the credentials already received, such as the user's fixed access key, and returns (if allowed) a new set of credentials to fulfill the role. This is the mechanism by which AWS can call other AWS services on your behalf, through which IAM instance profiles work in EC2, and through which the user can temporarily switch access levels or accounts in the AWS console.
The intended political role determines which principles (users, other roles, AWS) are allowed to call sts:AssumeRole for this role. In this example, access is granted to the EC2 service itself, which means that EC2 can perform actions on your behalf using this role.
This resource only is not useful as it has no IAM policies and therefore does not provide any access. Thus, the aws_iam_role resource aws_iam_role always be followed by at least one other resource to indicate its access permissions. There are several ways to do this:
- Use
aws_iam_role_policy to bind a policy directly to a role. In this case, the policy will describe the set of AWS actions allowed to perform the role and, possibly, other restrictions. - Use
aws_iam_policy to create an offline policy, and then use aws_iam_policy_attachment to associate this policy with one or more roles, users, and groups. This approach is useful if you want to attach a single policy to multiple roles and / or users. - Use special mechanisms to bind policies at the service level. This is another way to approach the problem, where instead of tying a policy to a role, it is tied to an object, access to which is controlled. The mechanism for this depends on the service, but, for example, the
policy attribute on aws_s3_bucket sets policies specific to a particular directory; The Principal element in a policy document can be used to indicate which principles (such as roles) can take certain actions.
IAM is a flexible system that supports several different approaches to access control. Which approach is right for you, you will largely depend on how your organization approaches security and access control issues: role-based policy management with aws_iam_role_policy and aws_iam_policy_attachment usually suitable for organizations that have a centralized security group that controls access throughout the account, while policies related to specific services delegate access control decisions to the person or team responsible for each individual object. Both approaches can be combined as part of an in-depth protection strategy, for example, using role-level and user-level policies to control “border” access (external access control) and service-level policies for internal access control tools (controlling the interaction between objects in your account )
For more information on roles, see the AWS IAM Guide. IAM Roles . See Also Access Control , which covers general concepts of access control in IAM.