Identity and Access Management (IAM) overview


What Identity & Access Management (IAM)?

IAM (Identity & Access Management) is the term used to describe the management of users, groups, policies and roles within AWS. It enables us to control users’ access to AWS resources at a very granular level and can ensure that only those that are authorised to carry out specific commands or functions in AWS are able to do so.

Where does IAM fit in your AWS environment?

IAM is a key building block to the security of your AWS environment. By managing permissions correctly and only granting the access level that is required, you can deliver a far more stable and well managed application environment and ultimately mitigate many security risks.

The above diagram shows Access Control (IAM) wrapping around all of the functionality and services in AWS. We have depicted it like this because it controls AWS user access; application access and end-user access to each of the services running in AWS.

Through this section we’ll cover off the functionality offered by IAM and some of the key terminology that you’ll need to know to effectively work as a solutions architect in an AWS environment.

What does IAM do and how does it work?

IAM offers extremely granular control of access rights provisioned to users. For example, if I have an environment of 100 instances (virtual servers) and want to allow a specific user to only manage one of those instances, I can do that – mitigating any risk that the user will carry out unauthorised activities with the other instances in the environment.

Through IAM, we can control who has access, what resources they have access to and what level of control they have over those resources.

In addition, we can grant access based on user location. We can do this as IAM enables us to define the source IP from which users can connect. So, we could limit access to those users that are currently sitting in the company offices. This control, coupled with physical security in the office adds a layer of security over your entire AWS environment.

We can further enhance security by enforcing a password policy for AWS users, ensuring that they are using strong, hard to crack passwords to login to your environment. These password policies, coupled with Multi-Factor authentication (which requires your account password in addition to a randomly generated passcode in order to login) provide another level of security on your AWS account.

IAM also enables us to set up temporary user access when needed – we can integrate with Microsoft Active Directory so that we can grant temporary permissions to users.

Now, let’s take a look at how IAM works with a scenario. Before we dive into the scenario, it’s important to understand a few terms which will be commonly referred to throughout this section:

  • Groups: enable us to group users together and manage their permissions from a single place. The alternative is to manage permissions, one user at a time which is very time consuming and prone to human error.
  • Roles: are used to provide permissions to other AWS services and IAM users.
    • Application roles: let’s say you have a server that runs an application that will need to access your S3 bucket. You’d need to assign that server a role & attach a policy to that role to enable the server to access the S3 bucket.
    • User roles: users can assume a role which will provide them with temporary permissions to other AWS services, such as S3.
      Note: only one role can be applied at a time but roles can be changed at any time.
  • Policies: policies are a set of rules that are applied to a user, group or a role. For example, applying the administrative access policy to a user would provide them with administrative access to all resources in AWS. AWS provides you with a number of pre-built policies to make administering your user groups easier.  If none of the pre-built policies suit your usecase, AWS offers a policy generator tool to help you build your own policy or you can even write your own from scratch. You can always test the policies you’ve written with the policy simulator, which helps you to understand whether your policy is working as you intended.
  • API Keys: API keys are required for Command Line access to your AWS resources and to utilize API calls to the AWS environment. You should note that API keys are generated and displayed only once. They apply to users only (roles do not have API keys) – if a user loses their API keys, they’ll need to deactivate the old keys & generate new ones.

Now that the general terminology has been covered, we can take a look at our scenario below:

In the above scenario, Bob and Carl are both part of the admin group in IAM. That group has a policy applied to it which grants access to S3 to all members of the group. As such, Bob & Carl are able to access the S3 bucket with no issues. If we want to revoke their access, we can do that at group-level, avoiding the management overhead of editing each account individually.

Helena isn’t a member of a group but has an S3 policy applied directly to her user account. This means that she is able to access the S3 bucket. To manage her permissions, we would have to do it at account level as she is not a member of a group.

Sam is a little different, he is accessing AWS services via the command line & as such requires API keys to use the AWS S3 service. Once he’s authenticated using his keys, AWS applies the policy that’s been attached to his account to manage his access and provision S3 privileges. We would have to edit Sam’s permissions at account level too as he is not a member of a group.

Side Note:

You may be wondering why there are two ways to provision access to a user – through a group or directly to their user account. Well, best practice is to manage user access privileges through groups. Why? Well, let’s say that you’re selling your company. The company acquiring you, have a legal team. This team need to carry out due diligence before they’ll commit to buy your company – the process will take 3 months. So you provision their team with access to the S3 bucket, intending to revoke that access in 3 months time. If you use a group to manage these users, you can revoke access to all users at the same time – with no risk of missing one or two users. Whereas, if you apply policies directly to the user account, you add additional administrative burden & risk accidentally leaving some users with access that they should not have.

What happens if someone has two policies assigned to them – one that allows access to Amazon S3 and the other denies access to Amazon S3? Well, an explicit deny ALWAYS overrides an explicit allow. That means, in this case, the user would be denied access to Amazon S3. Why is this useful? Well, let’s say a user goes on maternity leave. You don’t want them to have access while they’re away but you may not want to manually remove every policy now, just to put them all back in 9 months time. So, you can add a deny-all policy to the user, which will override any other policies attached to the users account.

The EC2 instance in the above scenario needs to be able to read and write to and from the S3 bucket for your application to run as it needs to. So, we apply a role to the EC2 instance allowing it to assume ‘user-like’ permissions to access the S3 bucket. Policies are then attached to the role in AWS, allowing us to easily edit permissions granted to the EC2 instance. It’s important to note that user API keys should NEVER be passed to an EC2 instance and API keys should never be stored on the instance.