The policies are defined with the help of the JSON syntax.
With Action you tell what kind of actions are allowed (in this case Create S3 bucket). Resources defines what resource this action affects (Here it’s the S3 bucket name can be anything because of ‘*’, it follows the regex rule. You can specify the resources too line this : “arn:aws:s3:::example_bucket”) Effect can either be “Allow” or “Deny”. You can also add more than one actions in lists. Make sure what are the actions available. In Example 2 you can see that I have mentioned ‘*’ in action for S3. That means that any action under S3 is allowed is for the user or the groups.
You can understand the above policy example 1 like this : “Allow to create a S3 bucket with the name you want”. If you attach this policy to a user, this user will be allowed to perform the mentioned action. If you attach it to a group all users in that group can perform this action. For example 2, you can read it like this: “Allow to create any action under S3 and you can name the resource as you like”.
Roles
Roles are similar to users as they hold an AWS identity with permissions. Roles are often used if you want to grant access to AWS resources that the users normally don’t have.
Another scenario would be that you want to grant an access to your AWS resources without exposing your AWS security credentials.
Once the IAM Role is assumed by an allowed entity, AWS Security Token Service (STS) provides the temporary security credentials to the entity. The temporary security credentials contain the following information.
- Session Token
- Access Key ID
- Secret Access Key
- Expiration
When an IAM user from a different AWS Account assumes an IAM role of another account (E.g. Using the Switch Account feature in AWS Console or using the API) the temporary credentials from STS will replace their existing credentials of the trusted account — The account they are from.