Please enable JavaScript.
Coggle requires JavaScript to display documents.
IAM - AWS Identity and Access Management (Implement application…
IAM - AWS Identity and Access Management (Implement application authentication and authorisation)
IAM Policy Basics
Principal
User, role, external user, or application that sent that request and the policies associated with that principal.
Action
What the principal is attempting to do.
Resource
AWS Resource object upon which the action or operations are performed.
Access through identity-based policies
Three types of identity-based policies.
AWS Managed
AWS Manages and creates these types of policies. They can be attached to multiple users, groups, and roles. If you are new to using policies, AWS recommends that you start by using AWS managed policies.
Customer managed
These are policies that you create and managed in your AWS account. This type of policy provides more precise control than AWS managed policies and can also be attached to multiple users, groups and roles.
Inline
Inline policies are embedded directly into a single user, group, or role. In most cases, AWS doesn't recommend using inline policies. This type of policy is useful if you want to maintain a strict one-to-one relationship between a policy and the principal entity that its applied to. For example, use this type of policy if you want to be sure that the permissions in a policy are not inadvertently assigned to a principal entity other than the one they're intended for.
IAM policy example
Statement
The Statement element is the main element for a policy. It can contain a single statement or an array of individual statements. Each individual statement block must be enclosed in curly braces {}.
Sid
The Sid element is optional and provides a brief description of the policy statement.
Effect
The Effect element specifies whether the statement will explicitly allow or deny access.
Action
The Action element describes the type of access that should be allowed or denied. The "*" shown here is a wildcard, which means that any Amazon SS3 action ending in "Object" will be allowed. Some examples include GetObject and PutOjbect.
Resource
The Resource element specifies the object or objects that the policy statement covers.
Granting Access
When you use the AWS API, the AWS CLI, or the AWS Management Console to take an action, such as creating a role or activating an IAM user access key, you send a request for that action.
First, IAM checks that the user (the principal) is authenticated (signed in) to perform the specified action on the specified resource.
Then, IAM confirms that the user is authorized (has the proper permissions) by checking all the policies attached to your user.
During authorization, IAM verifies that the requested actions are allowed by the policies.
IAM also checks any policies attached to the resource that the user is trying to access. These policies are known as resource-based policies. If the identity-based policy allows a certain action but the resource-based policy does not, the result will be a deny.
AWS authorizes the request only if each part of your request is allowed by the policies. By default, all requests are denied. An explicit allow overrides this default, and an explicit deny overrides any allows. After your request has been authenticated and authorized, AWS approves the actions in your request. Then, those actions can be performed on the related resources within your account.
Conditions
IAM allows you to add conditions to your policy statements. The Condition element is optional and lets you specify conditions for when a policy is in effect. In the condition element, you build expressions in which you use condition operators (equal, less than, etc.) to match the condition keys and values in the policy against keys and values in the request.
StringEquals
"Condition" : { "StringEquals" : { "aws:username" : "JohnDoe" }}
IpAddress
"Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
Policy Types
Identity-based
Also known as IAM policies, identity-based policies are managed and inline policies attached to IAM identities (users, groups to which users belong, or roles).
Impacts IAM principal permissions
Resource-based
These are inline policies that are attached to AWS resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy; hence, the principal policy element is required.
Grants permission to principals or accounts (same or different accounts)
Permissions boundaries
Restricts permissions for the IAM entity attached to it
AWS Organisations SCP
Organisation-level boundary: AWS Organizations is a service for grouping and centrally managing AWS accounts. If you enable all features in an organization, then you can apply SCPs to any or all of your accounts. SCPs specify the maximum permissions for an account, or a group of accounts, called an organizational unit (OU).
Restricts permissions for entities in an AWS account, including AWS account root users
SCP = Service Control Policy
ACLs
Access Control Lists
Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are supported by Amazon S3 buckets and objects. They are similar to resource-based policies although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.
