Skip to content

Latest commit

 

History

History
58 lines (43 loc) · 4.38 KB

iam.md

File metadata and controls

58 lines (43 loc) · 4.38 KB
Raw

IAM: Identity and Access Management

  • MFA: setup virtial MFA device, such as Google Authenticator.

When accessing AWS, the root account should never be used. Users must be created with the proper permissions. IAM is central to AWS. We can customize the passwords policy for users.

  • Users: A physical person; access type includes Programmatic access and AWS management console access.
  • Groups: Functions (admin, devops) Teams (engineering, design) which contain a group of users under one set of permissions. Groups cannot contain other groups.
  • Roles: Internal usage within AWS resources; create role (select the services that the roles are attached to) .
  • Policies (JSON documents): Defines what each of the above can and cannot do. Note: IAM has predefined managed policies.

For big enterprises:

  • IAM Federation: Integrate their own repository of users with IAM using SAML standard

Policies

IAM policies define permissions for an action regardless of the method that you use to perform the operation. Instance are region-sepecific, but the IAM is global, no matter which region the instances are.

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.

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

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

Quiz

  • Which is the best way to enable S3 read-access fro an EC2 instance? -- Create an IAM role with read-access to S3 and assign the role to the EC2 instance -- By default, the IAM user will have no access to the billing info; you can activate the access to billing in root account.