AWS IAM explained and why you don't need it

AWS is made of more than 165 services. And if you are using AWS whether it’s to host your website, use S3 for cloud storage, or manage a virtual server, you’ll mostly have to go through some permissions or policies: you’ll deal with IAM (Identity Access Management).

And it can be quickly overwhelming. Let’s explain IAM and why you don’t need it.

IAM core components

It’s a free AWS product that helps you define what users can access in your groups but also what resources they can use.

Whatever the action you are trying to achieve on an AWS service, you’ll have to go through IAM which will first identify you and then allow or deny the action according to the permissions that you have been granted.

The IAM infrastructure includes the following components:

• Principal: A person or an application that can make a request for action on an AWS resource. You can take the actions of creating a new EC2 instance or an API running on an AWS instance trying to access another service like S3.
• Request: A request is whatever action initiated to an AWS resource by a principal. Whether it’s using the AWS console, or the AWS API or the CLI, the principal sends a request to AWS.
• Authentication: Before using any AWS service, the principal must be authenticated whether it’s by using its credentials or access keys.
• Authorization: All AWS resources are denied by default. IAM will authorize a request only if the principal making the request is allowed.
• Action: Actions are to view, create, edit or delete a resource.
• Resource: A resource is an object that exists within a service. For example, looking at the AWS EC2 service, it’ll be an instance. It can also be an IAM user or an S3 bucket.

IAM Identities

Once you’ve understood the core components of IAM, it’s necessary to learn about the IAM identities. Put simply, IAM identity represents a user, user group, or role that can be authenticated and then authorized to perform actions in AWS.

They are made of Users, Groups, Roles, and Policies.

• Users
  

An IAM user is an entity with an associated credential and permissions attached to it. Whether it’s an application or a user, it allows the entity to execute certain tasks in AWS.

Each IAM user is associated with only one AWS account. By default, a newly created user is not authorized to perform any action in AWS. The root user of the AWS account will have to configure access and permissions for this account.

• Groups
  

An IAM User group is just a collection of IAM users. It’s useful for letting you assign permissions to multiple users who will have the same access or the same authorization. Note that users can also belong to multiple user groups. And when making changes to a group, it’s reflected on all users within that group.

• Policies
  

IAM permissions are assigned using policies. A policy is a set of permissions written in JSON format most of the time, depending on the type, describing permissions for action regardless of the method that is used to perform the operation.

There are actually 6 types of policies but for the sake of simplicity, we’ll describe the two most used policies.

Identity-based policies: The identity-based policy is a JSON permission policy document that contains actions a user, role, or group of users can perform on certain resources.

Resource-based policies: Resource-based policies are the ones that can be directly attached to the AWS resource like S3 ( called Amazon S3 bucket policy) for example. Resource-based policies are available only for certain services.

• Roles
  

An IAM role is a set of permissions that define what actions are allowed and denied by an entity. It is not necessarily associated with a single person, it can be used by anyone who needs it. A role does not come with credentials (password or access keys). It can be used temporarily by a user to access some resources for a specific task.

For example, you might want to grant temporary access to your account to a third party, such as a consultant or an auditor. They’re not permanent users, just users with temporary access to your environment.

That’s mostly concerning AWS IAM. IAM is a crucial part of AWS and, as a user, you will be confronted with it whether you want it or not.

In an environment where you need quick configuration, quick access, or temporal access but also efficient user managing, it can quickly become difficult and time-consuming, then you can use remote.it.

Now, why you don’t need IAM – Using remote.it

Working with AWS to grant access to resources and servers requires you to have to go through a lot of configuration, group creation, write policies, and make sure that access and rights are well dispatched. Sometimes, you might want to allow temporary access to someone or for a resource.

Remote.it simplifies a lot of these steps and allows you to give and configure access just by using the email addresses of the users you are looking to add to the AWS console.

Here are some advantages to using remote.it with AWS

• Control Use Access at the service level
• Eliminate IP accessibility
• Protect your network from the Internet discovery (No port opened then no scanning)
• Onboard and offboard users under minutes just using their email address

You can also share a specific device or even a specific service with a user. All you need is the user’s email address.

Using the organizations feature, it’s possible to add users who can automatically access your devices. In comparison to AWS IAM, it’s useful when you want your users to quickly onboard but it also reduces the configuration headaches with AWS IAM.

Conclusion

IAM in AWS is one of the most important concepts to understand to manage users and make sure access, authentication, and authorization are well set up. However, you can save yourself time and effort by using remote.it to manage access to your AWS resources.

‍