I'd be careful about modifying trust relationships - if they're poorly configured they can lead to your account or resource being compromised.
When granting explicit access to a user/group on the same account you should not be modifying the Trust Relationship of the role. To clarify further:
The roles should have a trust relationship of something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<YOUR ACC ID>:root"
},
"Action": "sts:AssumeRole",
}
]
}
What this essentially means is I'm delegating permissions to this role to the account listed in "arn:aws:iam::<YOUR ACC ID>:root"
-- its now up to the IAM operator of that account to grant access to this role using a policy such as this one:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Effect": "Allow",
"Resource": "<role arn>"
}
]
}
This policy can be attached to a user or group and that user or the users in the group will be able to assume the role that has the trust relationship above.
- A User can be placed in a group to gain the permissions associated with the group or can assume a role to enter a session where permissions are now that of the roles. Users have an access key and secret access key.
- Groups are only used to provide permissions to users, i.e a user is placed in a group.
- Roles are a temporary set of permission, i.e a user assumes a role and is granted temporary credentials for the life of the session. Role sessions will have an access key, secret access key, and a session token.