IAM users: Used for Human users, such as long term security credentials
IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance.
IAM principal: An identity defines within an AWS account
Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply.
Breaking down IAM Policy (JSON files):
'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny'
'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecure permissions
'Resource' clause: Exact resource ARN.
Policies attached to Resources (more granular level IAM policies):
Generally IAM polcicies apply to Principal, but in some scenarios, the policies can be attached to individual resources too, such who can access these resources and what actions can be performed. For example, an EC2 instance may want to access a S3 bucket from a different account. The plolciy attached to S3 bucket will decide if the EC2 from the other account can do such or not.
In this case there's be another additional clause 'Principal' (IAM arn) which indicates which role in other account can access this S3 bucket.
The decision is made on two factors:
- Does the S3 bucket have a policy allowing access from the calling IAM principal? (Resource based policy)
- Does the calling IAM principal have a policy allowing access to this S3 bucket? (Role based policy)
Cross account access needs Trust based policy:
Which says who can assume this role. In this case a resource can assume an IAM role from a different account.
IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance.
IAM principal: An identity defines within an AWS account
Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply.
Breaking down IAM Policy (JSON files):
'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny'
'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecure permissions
'Resource' clause: Exact resource ARN.
Policies attached to Resources (more granular level IAM policies):
Generally IAM polcicies apply to Principal, but in some scenarios, the policies can be attached to individual resources too, such who can access these resources and what actions can be performed. For example, an EC2 instance may want to access a S3 bucket from a different account. The plolciy attached to S3 bucket will decide if the EC2 from the other account can do such or not.
In this case there's be another additional clause 'Principal' (IAM arn) which indicates which role in other account can access this S3 bucket.
The decision is made on two factors:
- Does the S3 bucket have a policy allowing access from the calling IAM principal? (Resource based policy)
- Does the calling IAM principal have a policy allowing access to this S3 bucket? (Role based policy)
Cross account access needs Trust based policy:
Which says who can assume this role. In this case a resource can assume an IAM role from a different account.
Comments