Securing Access Management: Implementing IAM Best Practices for User Roles and Permissions

AWS Identity and Access Management (IAM) is key to securing our infrastructure.
In this article, I’ll share how I handle IAM access for our team, which includes various departments actively using AWS. My focus will be on AWS IAM Identity Center (formerly IAM SSO) and IAM Service.

For efficient management of access for different departments, teams, or individuals, those of us in DevOps, CloudOps, or SRE roles — essentially the owners of the infrastructure — must clearly understand the specific services each group will use and their intended purposes.

If we want a safe environment, we must follow the rule of giving each user only the minimum access they need. In simpler terms, we should practice the concept of least privilege access in our security approach.

Great, now let’s make a plan and list the steps we need to take to reach our goal.

1. Talk to the teams and team leads to find out which AWS services they use and what level of access they currently have in both production and non-production environments.

2. Assess whether the current access levels align with AWS security best practices. Remember, for AWS services in production environments, read-only access is usually preferable. Full access can be granted to certain AWS services in non-production (non-customer-facing) environments, allowing developers and engineers to conduct tests or POCs. However, always monitor the costs of AWS services, particularly when full access is provided in non-production environments for specific reasons.

3. Provide a clear and reasoned explanation of the security processes you’ve implemented and be ready to answer any questions and assist teams as needed. This step is particularly crucial if certain teams or individuals were previously granted full access everywhere without adhering to industry security standards, or if they might not even be aware of these standards. It’s important to help everyone understand the changes and the reasons behind them.

4. Implement changes gradually and announce them in a general channel for visibility. Include planned changes, their dates, and the estimated time they will take. This approach helps in keeping everyone informed and prepared for the upcoming adjustments.

Let’s assume we have four AWS accounts: development, sandbox-us, production, and Management. Developers and engineers use the development account for testing purposes. The sandbox-us account is used for live demos for potential customers. Our production workloads run on the production account. The Management account serves as a centralized location to oversee all other accounts. We should set up an IAM Identity Center in the Management account.

In this article, I won’t discuss the initial setup of IAM Identity Center or its integration with any external IdP services. That topic could be excellent for a separate article. One advantage of maintaining IAM users in the IAM Identity Center within the Management account is centralized management of users, groups, and permissions. By consolidating IAM users in a single account rather than managing them separately across different accounts, this approach saves time and effort, bringing simplicity and clarity to user management.

It is generally considered best practice to create groups and manage users at the group level. Additionally, it’s always beneficial to provide meaningful descriptions wherever possible to enhance clarity and understanding.

The next crucial component of our setup involves Permission Sets. A Permission Set acts as a template we create and maintain, encapsulating a collection of one or more IAM policies. By using Permission Sets, we simplify the process of assigning access to AWS accounts for users and groups within the organization.
For details please read this aws article https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html

To proceed, navigate to the IAM Identity Center main page and click on the “Permission Sets” button located on the left side of the screen.

When selecting Predefined Permission Sets, we will be utilizing AWS Managed Policies. On the other hand, opting for Custom Permission Sets allows us to create and employ custom IAM policies accordingly.
For our current purpose, we will select Predefined Permission Set and choose the ‘Administrator Access’ AWS managed policy as our policy type.

We have the flexibility to set any session duration that best suits our needs.

As you can observe, the Permission Set has been created but not yet provisioned. This means it hasn’t been applied to or utilized by any groups or users at this stage.

To proceed, we’ll go to the main page of IAM Identity Center and click on the “AWS Accounts” section located on the left side. From there, we’ll select the AWS account we want to work with.

Once the account is selected, the next step is to choose the group to which we will assign the permission set.

With this specific configuration, all users in the DevOps Group will have Administrator privileges within the sandbox-us account.

If we opt for the custom permission set option, we first need to create an appropriate IAM policy in the AWS account of interest. For instance, let’s assume we want to grant Read Only access to a few AWS services in the production account for the Backend Team.

After creating the specific (custom) IAM policy in the production account, we need to switch back to the management account.

When creating permission sets this time, we select the Custom Permission Set option. After clicking ‘Next,’ we can attach our custom policy by providing the name of the policy we previously created.

Please note that it’s crucial to accurately fill in the name of the custom permission set to ensure proper linkage and functionality.

The subsequent steps are quite similar to those we performed earlier. As soon as the new permission sets are applied, in this case to the production account, and the production account gets provisioned or re-provisioned, the Backend team members will immediately receive the appropriate accesses.

Another nice thing about this is that if we need to change anything in the custom policy later, we can just go to the production account, edit the policy, and save. These changes will automatically update in the permission set.

SumUp:

In summary, this article explored the efficient management of IAM in AWS, focusing on the use of IAM Identity Center for centralized control. It covered creating and managing user access across different AWS accounts (development, sandbox-us, production, and Management) using both predefined and custom permission sets. The article also emphasized best practices, such as assigning permissions at the group level and avoiding workloads in the management account, aiming to streamline IAM processes and enhance security in AWS environments.

I would be glad to receive any comments or feedback.

Enjoy reading.

Thanks!