Best practices for using AWS IAM groups and roles

Controlling who can access cloud-based applications can be tricky. The key is to grant enough access to some users, but not too much to others.

Moving applications to Amazon Web Services can elicit questions about how best to manage various pieces of the

cloud, specifically security and identity. But some security management questions are tougher to answer than others.

How should you give multiple users access to a single AWS account? Should all users have the same access privileges? Is there a way to allow apps to perform operations that require additional permissions? AWS Identity Access Management (IAM) can help streamline some of these security management operations via role- and group-based access controls. Before implementing these access controls, however, you need to understand the difference between AWS accounts and users.

AWS accounts, users and the foundation of group- and role-based access controls

AWS IAM is a centralized service for managing AWS users and user permissions; it serves many of the same purposes as Active Directory. An account is an entity within AWS that can create and manage resources. It's also responsible for billing.

All cloud users within one department can log into the same AWS account, which creates two problems. Like a root user in Linux, the account holder can perform virtually any supported operation in the AWS cloud. In addition, users would have to share credentials, such as usernames and passwords, to access the account. This limits the ability to audit which users are performing particular operations.

Administrators can create users associated with an AWS account; users have individual credentials and permissions for accessing AWS resources.

Define groups to manage similar users

AWS IAM admins could assign permissions to each user individually, but this could become difficult to maintain -- especially as the number of users grows. A better approach is to use groups.

Groups are collections of users that share a set of permissions and generally are created based on functions within an organization. For example, you may want to create groups for system administrators who need a wide range of permissions, developers who need the ability to launch AWS resources and application users who access AWS resources under the control of applications.

Users are added or removed from groups as their functional requirements change. When permissions are added, removed or modified from the group, those changes are applied to all users. As useful as groups are, there are times when it is best not to assign permissions directly to users.

Define roles to protect applications

A role is a set of permissions that are assigned to an AWS entity, such as an EC2 instance, so they can perform tasks that users would not normally be allowed to do.

A user may work with an application that saves data to an AWS S3 bucket, for example. To protect the integrity of the application data, users aren't given permission to write directly to the bucket. In this case, it's helpful to assign permissions using a role to the AWS EC2 instance running the application, so it can act on behalf of users.

Use roles for cross-account access

Many organizations will use multiple AWS accounts to manage their cloud resources. System administrators can create roles that grant permissions to users in one account to access resources in another account. This kind of cross-account access is useful when a workflow has multiple isolated steps needing multiple accounts.

This enables developers to use one account while testers use another. When code is ready to be pushed to testing, developers can write to resources the tester account owns if they have the appropriate cross-account access.

Practice granting least privilege

A long-standing information security principle is that users should only have the permissions they need to perform their duties -- and no more. This is known as the "principle of least privilege" and is designed to minimize the impact of a trusted user adversely effecting information systems.

You should also use least privilege when granting permissions to groups. Only grant permissions that all members of the group need to the group. If some members of a group need additional permissions, then create additional groups and assign the additional permissions to that group. Users that need additional permissions can be assigned to both groups. IAM groups and roles enable system administrators to grant permissions to users and applications as needed -- without allowing excessive privileges.

About the author:
Dan Sullivan holds a Master of Science degree and is an author, systems architect and consultant with more than 20 years of IT experience. He has had engagements in advanced analytics, systems architecture, database design, enterprise security and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail and education. Dan has written extensively about topics that range from data warehousing, cloud computing and advanced analytics to security management, collaboration and text mining.

This was first published in April 2014

Dig deeper on AWS security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudApplications

SearchSOA

TheServerSide

SearchSoftwareQuality

SearchCloudComputing

Close