AWS Memoires #2: IAM - Identity Access Management

Hi!

This post contains my notes on AWS IAM service.

What is IAM?

IAM stands for Identity and Access Management. It’s an AWS service that enables you to manage access to AWS services and resources securely. IAM is a global service and is offered without any additional charge. When you’re creating an AWS account, the default root user for your account will be created. Such user is not restricted in any way, hence it can be a security issue (especially when your root account gets compromised). Instead of using root account for your AWS work, you should create separate identities with permissions that follow the least privilege rule - so they have only the bare minimum privileges that are required for their tasks.

IAM identities

There are three types of identities offered by IAM:

  • IAM users - representing person or service who needs to interact with AWS. IAM user allows for signing in into AWS console or interacting with AWS resources via access keys. Newly created user will not have any permissions by default. You’ll have to grant them explicitly by adding user to a group or attaching permission policies directly
  • IAM groups - representing collections of IAM users. Groups reduce admin management overhead (by specifying permissions and attaching them to IAM group, you’ll make them propagate to all group’s users, which is a significant win over attaching permissions separately to each user). Any change in a policy attached to a group will be instantly applied to all users within the group.
  • IAM roles - role is an identity with permission policies that determine what the identity (that will be using the role) can and cannot do in AWS. It does not have any “static” credentials tied to it. Role can be assumed by anyone who needs it at the moment (even external users, for example users of mobile app). When a role is assumed, temporary credentials are generated and sent back to whoever successfully assumed the role.

Use cases for IAM users:

  • You created an AWS account and you’re the only person who works in your account
  • Other people in your company need to work in your AWS account, and your group is using no other identity mechanism

Use cases for IAM roles:

  • An application running on EC2 that has other AWS dependencies (for example it uses S3 its data store)
  • Mobile app that requests AWS resources
  • Providing your colleagues SSO (single sign-on) to AWS account (allowing users to federate into AWS)

IAM Policy

IAM policies are a set of rules that describe what is and isn’t allowed to be done with a particular AWS resource. They will be enforced only after they are attached to an identity (IAM user, group or role).

IAM policies are constructed using JSON.

{
  "Version": "2020-05-01",
  "Statement": [
    {
      "Sid": "FullAccess",
      "Effect": "Allow",
      "Action": ["ec2:*"],
      "Resource": ["*"]
    }  
  ]
}

“Statement” field of the policy is an array so there can be multiple statements inside a single policy. When an identity requests any AWS resource, it has to authenticate first (login+password or AWS access keys for programmatic access). When identity provides correct credentials, it becomes authenticated identity. AWS knows which policies are attached to this specific identity and access to particular resources can be granted/revoked.

Statement anatomy

  • “Sid” field - statement identity - an optional field that identifies statement; try to always include them in your policies and keep them as descriptive as possible
  • “Action” field - list of specific actions that will be controlled by the policy
  • “Effect” field - determines if actions from “Action” field are either allowed or denied (“Allow”/”Deny”)
  • “Resource” field - describes AWS resources that will be impacted by the policy

Wildcards are allowed within actions/resources fields (“*”).

Evaluation order for IAM policies

  • Explicit DENY has always highest priority
  • Explicit ALLOW
  • Implicit DENY by default

Since a single user can have multiple policies attached (coming from either directly attached inline policies or group membership) that might be overlapping, everything will be merged together using the above mentioned steps.

Inline policies vs managed policies

Inline policies are policies that are embedded directly into a single user, group or role. Imagine a scenario in which you’d like to grant write access to EC2 instance to several employees of your organization. When choosing inline policies for such a task, you’d have to add inline policy separately to each of the users. In case of any changes within permission scope, you’d have to again update each of employees separately. That sounds horrible from an administrator's point of view.

Inline policy would be a good candidate though for a situation requiring some kind of exception. It helps maintain a strict one-to-one relationship between a policy and the identity that it’s applied to. Using inline policy could prevent you from applying extra permissions to an identity by mistake - when you place some permissions that are designed for a specific person in managed policy, someone could reuse this policy by mistake and attach it to inappropriate identity, which could cause security breach. Deleting identity will automatically remove all policies attached to it.

Managed policies are standalone policies that can be attached to multiple identities. They can be either administered by AWS (AWS Managed Policies) or by a customer (Customer Managed Policies).

Let’s see how we could benefit from using managed policies when facing above-mentioned scenario:

  • Reusability - defining policy is a one-time action. Then we just attach it to identities that need it
  • Central change management - if you’d like to change the implementation of your policy, you do it in single place and the change is automatically propagated to all identities that have this policy attached
  • Versioning and rollback features - when you update a customer managed policy, the old version is kept. IAM stores up to five versions. This is very useful when you need a roll back.
  • Permissions management delegation - thanks to granularity of access that comes with IAM, you can allow other users in your account to attach and detach policies while maintaining control over the permissions defined in those policies.

Amazon Resource Name (ARN)

Amazon resource name (ARN) uniquely identifies resources within any AWS account. It is used in many places of AWS to avoid ambiguity.

ARN formats (format version depends on the resource):

  • arn:partition:service:region:account-id:resource-id
  • arn:partition:service:region:account-id:resource-type/resource-id
  • arn:partition:service:region:account-id:resource-type:resource-id

A bit more on IAM groups

IAM groups are containers for users. Groups are very helpful when dealing with administering user permissions. When you attach a policy to a group, it is propagated across all group’s users.

Group is not a true identity so it cannot be referenced as a Principal in policies. It serves the purpose of attaching policies to multiple users at one time.

Characteristic of groups: - Group can contain many users; user can be a member of multiple groups. - They do not allow for nesting - so you won’t be able to define a group within a group. - There is no default ‘all users’ group in your AWS account. If you’d need it, then you’d have to create and manage it on your own. - Number of groups within AWS account is limited. For details, please check this link. Please bear in mind that it is a “soft” limit, so it can be changed with the help of AWS support.

A bit more on IAM Roles

As mentioned before, IAM roles are not associated with any specific user or group. It’s a standalone identity which can be assumed by trusted entities (e.g. IAM users, applications, AWS services). Role consists of 2 parts: - Trust policy - JSON policy document containing a list of principals that will be allowed to assume the role - Permissions policy - JSON document which describes resources and actions that are allowed/denied on these resources

By leveraging IAM roles, you don’t need to manage any long-term access keys. Entity that is using the role will have to make AssumeRole call to AWS STS API (STS stands for Security Token Service). When everything is fine (calling principal is included in the trust policy), STS returns a set of temporary security credentials that allows for accessing resources according to permissions policy content.

There’s no charge associated with using IAM roles (other than the charge resulting from using actual AWS resources that are accessed with the role).

Roles can be “switched” in AWS console. By switching to another role, user temporarily gives up original permissions and uses permissions described in the role. When user exits the role, old permissions are restored.

Roles also allows granting access to identities outside of AWS account that were authenticated with external identity provider - for example user authenticates into mobile app with Facebook or Google login.

AWS Organizations

AWS Organizations introduces central government of your environment which is especially helpful when trying to scale your AWS usage within an organization.

Benefits that come with AWS Organizations: - Central management of policies across AWS accounts - Government of access to AWS services, resources and regions - Automating AWS account creation and management - Setting boundaries to services availability across multiple accounts (with service control policies - SPCs) - Consolidated billing across multiple AWS accounts

When creating an AWS organization, the account you’re using for this purpose will become the master account.

Service Control Policies (SPCs)

SPCs are policies attached on an organization level. They offer central control over the maximum available permissions for all accounts in your organization. What is interesting, SCPs allow for restricting root user (unless it belongs to a master account). SCPs do not grant any permissions themselves, they just specify account-wide limits.

There are 2 ways of defining the boundaries: - Allow list (block everything by default and explicitly add services that need to be accessed) - Deny list (allow by default, block only certain services explicitly). <- This is the default behaviour.

Exam essentials

  1. IAM is an AWS service that enables you to manage access to AWS services and resources securely.
  2. IAM is a global service.
  3. It’s free of charge!
  4. Secure your account as soon as possible (MFA, don't use root account for your day-to-day work).
  5. Three type of identities inside IAM - users, groups, roles.
  6. Use IAM users for persons/applications/service accounts that require long-term access to AWS account.
  7. There’s a hard limit for 5000 users per AWS account.
  8. Users can interact with AWS through either AWS web console (by authenticating with login & password) or programmatically (using AWS access keys).
  9. IAM groups are containers for IAM users.
  10. IAM groups allow for efficient administration - you attach a policy to a group and it will be propagated across all members of the group.
  11. IAM groups are not true identities, they cannot be referenced in policies.
  12. You can’t create a group inside a group (no nesting).
  13. IAM roles are standalone entities that consist of trust policy and permission policy. Trust policy determines principals that can assume the role. Permission policy describes actions that can be performed when a role is successfully assumed.
  14. IAM roles help with the burden of managing long-term credentials. When a role is successfully assumed, temporary security credentials are generated and sent back to the requestor (Security Token Service - STS).
  15. Roles can be switched within the console. When switching to a new role, you are losing your normal permissions and temporarily gaining the ones described in the role.
  16. IAM roles may come handy when a hard limit of 5000 users per account is a problem for you. You can authenticate users via external service (for example webidentity such as Facebook/Google/Twitter etc.) and let them assume certain roles in order to access AWS resources.
  17. IAM policies are a set of rules that describes what can and cannot be done with a particular resource.
  18. They will be effectively enforced only after they are attached to AWS identity.
  19. “Can” and “cannot” policy components are handled with statements.
  20. Statements consist of 4 fields: “sid” (statement identity), “action”, “effect”, “resource”.
  21. You can use wildcards (“*”) in “action” and “resource” fields.
  22. IAM policies are always evaluated as follows: - Explicit DENY (highest priority) - Explicit ALLOW - Implicit DENY by default
  23. Use inline policies only when you want to have a one-to-one relationship between policy and identity holding it (policy shall not be reused).
  24. If anyone else requires a similar kind of permission, use managed policy for it.
  25. Besides reusability, managed policies (customer managed) have versioning. AWS stores up to 5 versions of policy.
  26. User cannot edit AWS managed policies - but they are a good starting point for creating your own policies and can be built upon.
  27. AWS Organizations will help you scale your AWS environment.
  28. AWS Organizations allow for account-wide limits (which services can or cannot be used in this account) when combined with SCPs (service control policies).
  29. SPCs can be implemented in 2 ways: - Allow list (block everything by default and explicitly add services that need to be accessed) - Deny list (allow by default, block only certain services explicitly). <- This is the default behaviour.


That's all for today!
Best Regards,
Kuba