← all posts

AWS IAM

August 10, 2022
AWS IAM

DevOps AWS IAM 1

Untitled%2045.png

Untitled%2046.png

  • resources: the entities you create in AWS e.g. S3 bucket or EC2
  • Policy Statement
    1. Sid: name of this policy statement
    2. actions: perform actions on resources. e.g. createBucket. type of access that is allowed or denied access
    3. implicit deny: anything not explicitly declared is denied; explicit deny also denies; if both allow and deny are given, deny takes precedence (AWS first processes the deny list, then the allow list — if neither applies, the result is deny)
    4. resource: limit the scope of this action — which resource this action applies to
    5. principal: from the resource's perspective, determines who can use this resource. Less commonly seen because we attach policies to principals (either a role or a user). Definition: the entity that is allowed or denied access (i.e., who this policy targets)
    6. condition: constraints that you can apply to your policy docs depending on context
  • When a Policy is assigned to a user, that user can operate on resources via the AWS UI console, CLI, and SDK according to that policy
  • Amazon Resource Name (ARN): uniquely identifies an AWS resource; some segments can be omitted and replaced with :: e.g. arn:partition:service:region:account-id:resource-type:resource-id
  • trust relationships: account1 trusts account2, and account2 trusts account1, so accounts can consume roles from each other
  • Least privileged model: grant only the permissions necessary to perform a task

IAM policies:

  1. Who should have access to do what?
  2. AWS Evaluation: can this person call this action on this resource

when you define access policies. You specify which IAM principals are allowed to perform which actions on specific AWS resources and under which conditions

DevOps AWS IAM 2

1411662087834_.pic.jpg

  • Policies are divided into identity-based policies and resource-based policies
    1. These two are completely independent of each other. A resource-based policy is viewed from the resource's perspective — it defines which principals can access this resource. It cannot be applied in bulk; each resource's policy is assigned individually based on context and cannot be reused across resources.
    2. An identity-based policy is viewed from the user, group, or role's perspective — it can be reused and applied in bulk.
  • roles: used by non-login entities (not Group/User) to access AWS services, connecting AWS services to IAM. When you have an EC2 instance, you create a role so it can connect to S3.
  • Each policy can have multiple statements, but each statement belongs to only one policy
  • resource-based policies are mainly configured within each service's console — they define permissions between services, allowing a service to communicate with its corresponding resource
  • Both roles and resource-based policies can enable resource-to-resource communication (provided the role contains the relevant resource-based policy)
;