AWS Startups Blog

How Setting Up IAM Users and IAM Roles Can Help Keep Your Startup Secure

by Kevin Shaffer-Morrison, AWS Startup Solutions Architect and Faisal Farooq, AWS Startup Solutions Architect

For startups, speed is critical — you’re trying to move as quickly as possible to build your product and find product-market fit. Even as you focus on growing your business, however, it’s important not to ignore your security posture. If attackers gain access to your systems, they can disrupt your business operations and cause serious — even fatal — reputational damage. There are some simple steps you can take, however, that will allow you to move quickly while still safeguarding your data. A key one is to employ Identity and Access Management (IAM) users and roles.

An IAM user is an individual, such as an engineer, who needs access to your AWS account, whether through the AWS Management Console, command line interface, or your favorite AWS SDK. Occasionally, there may also be circumstances in which certain third-party applications also need access to your AWS resources (e.g., a CI/CD tool such as CircleCI, or Github actions). In these situations, you can also create an IAM user for that application, with policies for the service to carry out specific actions, such as deploying a new AWS Lambda function or pushing a container image to Amazon Elastic Container Registry (Amazon ECR) and deploying an Amazon Elastic Container Service (Amazon ECS) Task. IAM users can be assigned a variety of credentials, such as passwords and access keys. Creating individual IAM users also allows you to limit their permissions to just the tasks and resources that are needed for the job.

Consider the following scenario: Bob has an AWS account that he needs to access, and he is using a third-party CI/CD system that needs to upload Docker images to the ECR upon every build. Bob can access the AWS account via the AWS web console using his username and password as an IAM user. He also can leverage the AWS Command Line Interface (AWS CLI) and AWS SDKs by using his user access keys. But the CI/CD system isn’t a human, so how can Bob provide it with access to Amazon ECR? To do this, Bob can create an IAM user for the CI/CD system with programmatic access, and an IAM policy that allows writes to ECR. He can then securely share those keys with the CI/CD system so that it can interact with AWS services.

Whether IAM users represent humans or applications, it’s important to follow these best practices:

There is one potential downside of using IAM users, however: Establishing long-term static credentials can pose a security risk. If an attacker compromises Bob’s IAM user credentials, they can use those credentials for as long as they remain valid — which is even more problematic if the associated permissions do not follow the principle of least privilege. Until the unauthorized use is detected and access is revoked, the attacker can continue using the access keys unhindered.

One way to reduce this threat is to use temporary credentials instead of long-term static credentials. Luckily, AWS provides an easy way to create such temporary credentials: IAM roles.

IAM Roles

An IAM role is similar to an IAM user: It is an AWS identity with certain permission policies that dictate what the role can and cannot do. A role does not have long-term static credentials such as a password or access keys associated with it. Instead, individuals and third-party applications “assume a role” in order to obtain temporary credentials and permissions for the duration of that role, known as a role session. You can read more about IAM roles in the AWS IAM user guide.

This scenario illustrates how roles can help you improve your AWS security posture:

Yuri, a developer working at a startup, wants to access their AWS Staging account to test their changes in a staging environment before the application is deployed in production. Yuri has user credentials to access the startup’s Dev AWS account. Now, when Yuri wants to access resources in the Staging AWS account, she has the permission to assume a Tester IAM role, which grants her privileges to access resources in the Staging AWS account. When Yuri assumes a role, she gets temporary credentials by way of an access key pair for the duration of the role session.

Let’s also consider the permissions of a senior developer on the team, Joy. She also has user credentials in the Dev AWS account, and just like Yuri she has permissions to assume a Tester role in the Staging AWS account. As a senior engineer, Joy also has permissions to assume an IAM role to access resources in the Prod AWS account. Joy’s access to the Prod AWS account is through an IAM role, which provides her with temporary security credentials for the duration of the IAM role session.

This setup ensures that this startup’s AWS accounts are segmented (Dev/Staging/Prod), and only temporary access is granted to the Prod and Staging accounts via IAM roles.

It is important to leverage IAM roles and segment workloads in different AWS accounts. Such segmentation ensures that a misconfiguration or compromised account has a reduced impact. If a user’s credentials are compromised, the attackers will have limited access to other environments.

Applications and services can also assume IAM roles. We often see developers embed IAM user access keys to configure the AWS SDK in an application running on an Amazon Elastic Compute Cloud (Amazon EC2) instance. This is a bad practice, however, because long-term static credentials pose a security risk. If an attacker compromises the EC2 instance, they can access data in Amazon Simple Storage Service (Amazon S3) and other resources based on the permissions associated with the IAM user.

The AWS-recommended best practice is to leverage IAM roles instead. Amazon EC2 instances can assume IAM roles, called instance profiles, to access AWS services, such as Amazon S3. This provides temporary credentials for AWS services and resources that are valid for the duration of the role session.

Once you’ve set up IAM users and IAM roles, there are a few more simple steps you can take to maintain a strong security posture as you build your startup. First, download the credential report from the IAM console and remove any user access keys that are being used in your applications where an IAM role would be more appropriate. Next, run a scan on your codebase to make sure no hard-coded user access keys are still lingering.

From there, you can consider using tools such as Prowler to scan your AWS account and ensure you are following security best practices. You can even send your results to AWS Security Hub for easy analysis. At AWS, security is our top priority, and we’re happy to answer any questions you might have and offer additional guidance.

We know that security can often become an afterthought when you’re moving at warp speed. But implementing these basic security best practices early on will reduce the risk to your startup and enable you to scale your development team more easily, setting you up for long-term success.