Identity management in AWS

We will look at how we can manage users and their permissions. In addition, I will try to show you how you can approach it starting with one AWS account, then moving on when the number of accounts begins to grow.

Access to AWS account

You start your adventure with AWS, you set up your first AWS account. You have a login (in the form of an email address and password). So it’s time to launch the first service!

Wait, wait, but is it safe to work on the root account (this account with the login as an email address)?

Exactly, this is a topic that I remind you about every time.

Principles of working with AWS:

1. Do not use the root account on a daily basis.
2. See point 1.

So let’s get to the specifics….

Manage one AWS account

If you have only one account at the beginning, then the matter is quite simple.

In AWS, you will find a service such as Identity and Access Management (IAM), which is used to manage access and permissions within a single AWS account.

Therefore, the first step after creating an AWS account is to go to this service and create a user (the so-called IAM User), which you will use on a daily basis to work with AWS.

The basic properties of this service are:

• User management,
• Configuration of groups and user affiliations,
• Permission management using IAM Policies,
• Management of access to permissions between services,
• Password policy, etc.

In summary, if you work on one AWS account, use this service to manage all accesses and permissions for your resources.

Cross-Account Access

But what if we use more AWS accounts? Let’s say there is a situation where I have two accounts: Developer and Production.

We need users from the Developer account to be able to access resources or make configurations in the Production account.

We have two options here:

Option #1: Create an additional IAM User in the production account.

However, this method has some drawbacks.

First of all, the employee now has two logins, two passwords (or even more if there are more AWS accounts).

Secondly, from an administrative point of view, as the number of accounts increases, the amount of work related to managing users and accounts increases.

In addition, there are additional account IDs, URL to the console, etc.

Option #2: Use Cross-Account Access options.

How does it work? Let’s go back to our scenario, two accounts, Developer and Production.

At the development end we have a team of users, everyone has their own IAM User, associated with IAM Group – Developers.

Now this team needs to get to the resources located at the Production end.

For this purpose, IAM Role was created at the Production end, thanks to which the development team will be able to “switch” to the Production account.

IAM Role is associated with appropriate permissions, according to what the team needs to do their job.

Therefore, we are left with one login, and more accounts. But still configure the appropriate IAM Roles, remember names, etc.

Details of how to configure such access can be found HERE

AWS Single Sign-On

We are now moving on, and what if the number of accounts in our organization is constantly increasing?

There are challenges associated with creating appropriate IAM ROLES on each of the accounts, users must remember the ID of AWS accounts, and the names of IAM Roles that are associated with them.

Of course, we can automate part of the post-facial configuration. Users can install additional browser plug-ins to manage shortcuts for switching between accounts.

I once made such an “ala” console with links to the AWS role account (console.lukado.eu), where I aggregated all the necessary URLs.

So access management is still highly distributed.

Fortunately, it can be done even differently….

In AWS there is an AWS Single Sign-ON service, which, as the name suggests, provides SSO for various applications, including AWS accounts, which we manage within our organization.

The service allows us to:

• Manage the applications to which you will be able to access (including AWS accounts),
• Create users and groups (crazy when AWS SSO has its own user directory),
• Grant appropriate permissions,
• Integrate with external Identity Providers,

For example, if you use Microsoft365, where Azure AD is also a user directory, you can associate it with AWS SSO. Then users and groups “flow” from the external Identity, and in AWS SSO you grant permissions to the appropriate AWS accounts or other applications.

You can find more about it HERE

But our company already uses ADFS

Large organizations often already have implemented mechanisms for accessing internal systems, e.g. based on ADFS.

At the moment when such an organization plans to implement cloud solutions, the question immediately arises. What about access management, can it be integrated?

Here, of course, there is no problem for the company’s employees to log in from AWS using, for example, the already mentioned ADFS.

It is only required to prepare the appropriate integration.

More on how to do it can be found HERE

Remember that all these elements can be fully automated. It is mainly about the configuration and connection with ADFS for each new AWS account that is created within our organization.

As an example for this purpose, we can use, the AWS CloudFormation service.

Thanks to AWS Organization and CloudFormation StackSets, we can prepare the entire basic configuration (e.g. configuration of roles and ADFS as An Identity Provider) and deploy it to each new account.

Summary

Depending on the operating model, scale and requirements of our organization, there are several solutions to choose from.

REMEMBER, don’t use the “root” master account to work with AWS…

And then choose solutions that meet your needs.

ONE ACCOUNT – IAM service and each employee has their own IAM User.

MORE ACCOUNTS – IAM and Cross Account Access service, or AWS SSO,

Integration with ADFS or another provider – also the most to do, it’s just a matter of proper configuration.