Skip to content

Latest commit

 

History

History
113 lines (96 loc) · 6.61 KB

iam.md

File metadata and controls

113 lines (96 loc) · 6.61 KB
Raw

IAM: Identity and Access Management

  • When accessing AWS, the root account should never be used. Users must be created with the proper permissions. IAM is central to AWS
  • Users: A physical person
  • Groups: Functions (admin, devops) Teams (engineering, design) which contain a group of users
  • Roles: Internal usage within AWS resources
    • Cross Account Roles: roles used to assumed by another AWS account in order to have access to some resources in our account
  • Policies (JSON documents): Defines what each of the above can and cannot do. Note: IAM has predefined managed policies
    • There are 3 types of policies:
      • AWS Managed
      • Customer Managed
      • Inline Policies
  • Resource Based Policies: policies attached to AWS services such as S3, SQS

Policies

  • IAM policies define permissions for an action regardless of the method that you use to perform the operation.

Policy types

  • Identity-based policies: attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity
  • Resource-based policies: attach inline policies to 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 a principal entity that is specified in the policy. Principals can be in the same account as the resource or in other accounts
  • Permissions boundaries: use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity
  • Organizations SCPs: use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions
  • Access control lists (ACLs): use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs 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 entity. ACLs cannot grant permissions to entities within the same account
  • Session policies: pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user's identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see Session Policies

Policies Deep Dive

  • Anatomy of a policy: JSON document with Effect, Action, Resource, Conditions and Policy Variables

  • An explicit DENY has precedence over ALLOW

  • Best practice: use least privilege for maximum security

    • Access Advisor: a tool for seeing permissions granted and when last accessed
    • Access Analyzer: used of analyze resources shared with external entities

  • Common Managed Policies:

    • AdministratorAccess
    • PowerUserAccess: does not allow anything regarding to IAM, organizations and account (with some exceptions), otherwise similar to admin access

  • IAM policy condition:

    "Condition": {
    "{condition-operator}": {
        "{condition-key}": "{condition-value}"
    }
}

  • Operators:

    • String: StringEquals, StringNotEquals, StringLike, etc.
    • Numeric: NumericEquals, NumericNotEquals, NumericLessThan, etc.
    • Date: DateEquals, DateNotEquals, DateLessThan, etc.
    • Boolean
    • IpAddress/NotIpAddress:
      • "Condition": {"IpAddress": {"aws:SourceIp": "192.168.0.1/16"}}
    • ArnEquals/ArnLike
    • Null
      • "Condition": {"Null": {"aws:TokenIssueTime": "192.168.0.1/16"}}

  • Policy Variables and Tags:

    • ${aws:username}: example "Resource:["arn:aws:s3:::mybucket/${aws:username}/*"]
    • AWS Specific:
      • aws:CurrentTime
      • aws:TokenIssueTime
      • aws:PrincipalType: indicates if the principal is an account, user, federated or assumed role
      • aws:SecureTransport
      • aws:SourceIp
      • aws:UserId
    • Service Specific:
      • ec2:SourceInstanceARN
      • s3:prefix
      • s3:max-keys
      • sns:EndPoint
      • sns:Protocol
    • Tag Based:
      • iam:ResourceTag/key-name
      • iam:PrincipalTag/key-name

Policy Evaluation Logic

  • Components involved in a policy evaluations:
    • Organization SCPs
    • Resource Policies
    • IAM Identity Boundaries
    • Session Policies
    • Identity Policies
  • Policy evaluation logic - same account: policy evaluation logic - same account
  • Policy evaluation logic - different account: policy evaluation logic - different account

AWS Policy Simulator

  • When creating new custom policies you can test it here:
  • Alternatively, you can use the CLI:
    • Some AWS CLI commands (not all) contain --dry-run option to simulate API calls. This can be used to test permissions.
    • If the command is successful, you'll get the message: Request would have succeeded, but DryRun flag is set
    • Otherwise, you'll be getting the message: An error occurred (UnauthorizedOperation) when calling the {policy_name} operation

IAM Roles vs Resource Based Policies

  • When we assume a role (user, application or service), we give up our original permission and take the permission assigned to the role
  • When using a resource based policy, principal does not have to give up any permissions
  • Example: user in account A needs to scan a DynamoDB table in account A and dump it in an S3 bucket in account B. In this case if we assume a role in account B, we wont be able to scan the table in account A

Best practices

  • One IAM User per person ONLY
  • One IAM Role per Application
  • IAM credentials should NEVER be shared
  • Never write IAM credentials in your code. EVER
  • Never use the ROOT account except for initial setup
  • It's best to give users the minimal amount of permissions to perform their job