IAM users
By default, a new Identity and Access Management (IAM) user has no permissions assigned to them. The user is not authorized to perform any AWS operations or access any AWS resources. An advantage of having individual IAM users is that you can assign permissions individually to each user.
Setting permissions with IAM policies
To allow IAM users to create or modify resources and perform tasks:
- Create IAM policies that grant IAM users permission to access the specific resources, and API actions they will need.
- Attach the policies to the IAM users or groups that require those permissions.
Users only have the permissions specified in the policy. Most users have multiple policies. Together, they represent the permissions for that user.
IAM roles
IAM roles deliver temporary AWS credentials. They’re easy to manage because multiple employees and applications can use the same role. Use roles to delegate access to users, applications, or services that don’t normally have access to your AWS resources.
Roles can be assumed through the API call, using one of the following:
- The console
- AWS CLI
- AssumeRole API
- AWS Security Token Service (AWS STS)
The AssumeRole action returns a set of temporary security credentials consisting of an access key ID, a secret access key, and a security token. AssumeRole is typically used for cross-account access or federation.
Policy types
Identity-based policies
You attach managed and inline policies to IAM identities. This includes users, groups to which users belong, and roles.
Resource-based policies
You attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies.
IAM permissions boundaries
An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. Use a managed policy as the permissions boundary for an IAM entity (user or role). The managed policy limits the permissions that the identity-based policy can grant to an entity. It does not grant permissions.
AWS Organizations service control policies (SCPs)
Use Organizations SCPs to define the maximum permissions for account members of an organization or organizational unit (OU).
Access control lists (ACLs)
Use ACLs to control which principals in other accounts can access a resource to which the ACL is attached. ACLs are similar to resource-based policies. However, they are the only policy type that does not use the JSON policy document structure. We will discuss ACLs in more detail in Module 3.
Policy elements
| ElementDescriptionEffectUse Allow or Deny to indicate whether the policy allows or denies access. PrincipalIf you create a resource-based policy, you must indicate the account, user, role, or federated user to which you want to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role. ActionInclude a list of actions that the policy allows or denies.ResourceIf you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, the resource to which the action applies is the resource to which the policy is attached.ConditionSpecify the circumstances under which the policy grants permission. |
|---|
Explicit allow and explicit deny
Use IAM policies to allow and deny access to resources.
{
"Effect": "Allow",
"Action": ["s3:ListObject”, “s3:GetObject”],
"Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"]
}
The following policy denies access.
{
"Effect": "Deny",
"Action": [”ec2:*", "s3:*"],
"Resource": “*”
}
When a principal tries to use the console, the AWS API, or the AWS CLI, that principal sends a request to AWS. When an AWS service receives the request, AWS completes several steps to determine whether to grant or deny the request.
By default, all requests are denied. This is called an implicit deny. The AWS enforcement code evaluates all policies within the account that apply to the request. These include Organizations SCPs, resource-based policies, IAM permissions boundaries, role session policies, and identity-based policies. In all those policies, the enforcement code looks for a deny statement that applies to the request. This is called an explicit deny. If the code finds even one explicit deny that applies, the code returns a final decision of deny. If there is no explicit deny, the code continues.
How IAM policies interact with SCPs
An SCP is a type of organization policy that you can use to manage permissions in your organization.
Attach identity-based or resource-based policies to IAM users, or to the resources in your organization’s accounts. Attach an SCP to an Organizations entity (root, OU, or account) to define a guardrail. The SCP sets limits upon the actions that the IAM users and roles in the affected accounts can perform.
Regards
Osama
Technology Geek 