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

AWS Policy Simulator

• When creating new custom policies you can test it here:
  • https://policysim.aws.amazon.com/home/index.jsp
  • This policy tool can you save you time in case your custom policy statement’s permission is denied
• 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