[Part 1] The Least Privilege Principle and IAM in AWS

Nishant Thorat
April 16, 2024
5 min read

his blog series dives deep into implementing the principle of least privilege with Identity and Access Management (IAM) for robust security in your AWS environment. 

The principle of least privilege (PoLP) is easier to understand until you put it into practice. It is easier to practice when the footprint of your environment is small. However, as the footprint increases, the effort to keep up with the PoLP becomes more difficult. In this series, we will discuss PoLP, how to set up accounts and guardrails, what tools to use, what process to follow, what technical and managerial challenges you may encounter, how to tackle them, and so on. But before we delve into the specifics of IAM and least privilege, let's establish a common ground by understanding the core principle itself.

The Least Privilege Principle: Granting Just Enough Access

The least privilege principle is a fundamental security concept that dictates granting a user or role (aka principal when including machine identities) only the permissions required to perform a specific task. In simpler terms, it boils down to "giving the least amount of access necessary to get the job done". This approach minimizes the potential damage if an attacker gains unauthorized access to a user account or role. 

Imagine a well-fortified castle. The king resides in the inner sanctum, with access to all areas. But the baker only needs access to the kitchen, and the guard only needs access to the gatehouse. By following the principle of least privilege, you create a layered security posture within your AWS infrastructure, just like the different access levels in the castle.

Least privileges in a castle
AI Generated Image

Here's a quick breakdown of the benefits of adhering to the least privilege principle:

  • Reduced Attack Surface: By granting minimal permissions, you significantly reduce the attack surface available to malicious actors. Even if an attacker compromises a user account, their ability to cause harm is limited by the restricted permissions associated with that account.
  • Enhanced Security Posture: The least privilege strengthens the overall security posture by minimizing the potential impact of security breaches. 
  • Improved Compliance: Many security regulations and compliance standards mandate the implementation of least privilege for user access controls.SaaS compliance standards such as SOC 2 specifically require to demonstrate safe user access to critical resources.
  • Reduced Costs: By preventing unauthorized access to resources, you can help to reduce your cloud computing costs. Users with excessive permissions may inadvertently or accidentally provision or use resources that are not needed, leading to unnecessary costs.

Challenges of Implementing Least Privilege

While the benefits of least privilege are undeniable, implementing it effectively can be challenging, especially in dynamic cloud environments like AWS. Here are some common hurdles you might encounter:

  • Granular Permission Management: Cloud environments can be complex, with many resources and permissions. Defining granular permissions for a large number of users and roles can be time-consuming and complex.
  • User Resistance: Users accustomed to broader access might resist changes that restrict their permissions, especially if it makes it more difficult for them to do their jobs. They may be accustomed to having broad permissions and may not understand the importance of least privilege. Effective communication and training are crucial to address these concerns.
  • Operational Overhead: Maintaining the least privilege requires ongoing monitoring and review of user permissions to ensure they remain aligned with evolving needs.

While at the outset the least privilege looks more like a binary choice, in practice due to the factors mentioned above it is more of a balancing act.

Scaling Challenges: SSO and Complexities

Federated access using Single Sign-On (SSO) may seem like the perfect solution for startups that are expanding. It allows users to access all their cloud resources with just one login, making it easier to use and increasing productivity. However, as your AWS presence grows, this method can become more complicated and reveal some hidden complexities.

Multi-Account Management:  As your company grows, you may require multiple AWS accounts for different purposes such as development, testing, production environments, or regional deployments. Although federated access makes user login easier, it doesn't remove the need to set up SSO for each AWS account (unless AWS SSO is used). As the number of accounts increases, this can become a time-consuming and error-prone process.

Complex Permission Structures:  Managing user permissions across multiple AWS accounts can be challenging. Each account may have its own resources and policies, making it difficult to ensure that users have the appropriate level of access required for their tasks across all accounts. For instance, a developer may need access to development and testing environments, but not the production environment. Configuring these permissions manually across multiple accounts can be a nightmare. 

Increased Operational Overhead:  Maintaining multiple SSO configurations and managing complex permission structures across numerous AWS accounts can significantly increase operational overhead. This can lead to cloud/security teams spending more time managing and troubleshooting access than focusing on strategic initiatives.

Security Concerns: SSO, or Single Sign-On, can make accessing multiple AWS accounts easier. However, it's important to keep in mind that if a user account with extensive permissions is compromised, it could pose a major security risk. Typically, privileged cloud admin accounts have broad permissions and access to all AWS accounts. In the event of a single point of failure, a significant security breach could occur. That being said, there are alternative ways to manage access as your startup grows, which we'll explore in the next few sections.

Taming the Beast: AWS IAM Identity Center

As your startup grows and you start managing multiple AWS accounts, you'll realize that managing user permissions can get complicated. That's where the AWS IAM Identity Center comes in. It acts as a central control tower for all your AWS access needs. The IAM Identity Center is a single entry point for managing users and their access to all your AWS accounts. You can even use your existing corporate identities from services like Google Workspace or Okta to ensure a consistent login experience for your users.

Simplified Permissions Management: The Identity Center simplifies permission management by allowing you to define permissions based on user roles and assign those roles to users or groups while enforcing least privilege principles.

Streamlined Operations:  Consolidating user and access management in a single console, Identity Center simplifies your operational processes. For instance, you can add a new employee and grant them access to the appropriate AWS resources from a centralized location. 

To streamline your AWS management, consider following these strategies:

Least Privileges Balancing Act
Least Privileges Balancing Act

To quote, VP and Distinguished Engineer at Amazon Security, Eric Brandwine, “Least privilege equals maximum effort.” While most organizations start at the left end of the spectrum, reaching the right end is impractical. The idea is to balance the developer/engineer productivity with the maximum possible security. 

Least Privileges is about people and processes too

The cloud security teams that have decided to pursue an ever elusive goal of building a strict least privileged environment often mistake it simply as a technical challenge. This is a deadly mistake, which often leads to the failed least privileges initiative. As Badshah discusses in his interesting blog post, failures in combining technology, people, and processes can be disastrous to your least privileged ambitions.

The least privileges for humans and machines

The least privileges principle applies to access by machine and human identities. 

Machine identities include access by scripts or applications and come in the form of service accounts or IAM users. In a way, it is easier to apply the PoLP to machines, as it is predictable and can be understood from the code. The code changes also go through reviews and follow the change management process making them much easier to keep in the state of PoLP. 

On the other hand, human behavior is unpredictable and often does not strictly follow the change process and reviews. It would be possible for a privileged cloud admin to create new IAM users with wider access permissions or update existing IAM users/roles to add wider access permissions without going through a proper change management process. To ensure such privileged users do not abuse (insider threat) or an attacker does not misuse the privileges real-time monitoring of the actions performed, session monitoring, and just-in-time access approvals should be used.

Human Identity Access
Machine Identity Access
Permissions should be broad enough for engineers to do day-to-day work.Protect the privileged access with just-in-time access request tools such as CloudYali AccessGuard.
Permissions should be precise/exact as seen in the code or requested by developers.
Not too restraining to avoid frequent requests to cloud/security teams for additional access. Not bound to specific resources. Common resources across accounts such as logging, audit trails, Security Hub, etc should be protected through just-in-time (JIT) access.
Bound to specific resources or resource groups. Applications interact with specific and known resources such as S3 buckets for application logs or storing reports. Thus it is possible to write IAM policies with access only to the application-specific cloud resources.
Proper guardrails need to be established. Users should not be able to change basic security posture or lockout themselves or cloud/security teams from the environment.
Baked into infrastructure as code
The operating environment and context dictate the access permission broadness assigned to the users. E.g. Production environment permissions only to cloud/security teams and not to the development team.
The permissions will be tightened in each stage of the application development and deployment path (Development/Testing/Staging and Production).
In most organizations, the privileged access permissions assigned to humans are generally long-standing. These permissions are not revoked even though people change teams or are not required beyond on-call duties. Just-in-time (JIT) access management tools such as CloudYali AccessGuard help to assign access permissions only for the required duration.
Machine identities assume roles and access permissions as needed.

Context defines the Least Privileges strategy

Everyone understands that the least privileges mean not having excessive permissions.  Surprisingly, what constitutes excessive permissions is defined by the purpose of the AWS account as well as the kind of workload hosted by the AWS account. What is permissive in one type of environment may be viewed as excessive in another environment and context solely defines the excessiveness.

An AWS recommended pattern is to use multiple AWS accounts for hosting different products and workload types. This pattern uses a minimum of three AWS accounts: Development, QA, and Production for each product or service. In addition to the accounts for each product, common services such as security logs or CIEM tools are hosted in a common security AWS account.

Dev Accounts - freedom to experiment

The Dev AWS accounts should be the least restrictive allowing developers the freedom to build and experiment. The access permissions in this account should be broad enough such that the developers don’t have to reach out to Cloud/Security teams for new permissions often. This round-trip saving is mutually beneficial for both developers and cloud teams. Not all developers are equal, and these broad permissions should be available only to senior developers.

Context defines least privilege strategy
Access Spiral

QA Accounts - monitor and refine

On the other hand, the QA AWS account should have tooling installed to measure the actual permissions and resources used. This monitoring and measurement helps to tighten further the actual AWS permissions used. Many AWS native, commercial, and open-source tools can be used to achieve this. 

Production Accounts - Strict Hygiene

Lastly, the production AWS account should have the least amount of permissions refined through an iterative process. The account should also have (almost) zero human access to it. In the perfect universe, all the updates to this account should happen via Infrastructure as Code. Of course, we do not live in a perfect universe, and in such exceptional cases, human user access should be approved and revoked via Just-in-time access request tools such as CloudYali AccessGuard.

Why Use IAM for Least Privilege in AWS?

AWS Identity and Access Management (IAM) is a service that helps you control access to your AWS resources. IAM allows you to create users, groups, and roles, and to grant them permission to perform specific actions on AWS resources. IAM is a core service for implementing the least privilege principle in AWS.

The AWS IAM supports three core functionalities:

  • Authentication: IAM authenticates users who are trying to access AWS resources. This is typically done using AWS credentials, which consist of an access key ID and a secret access key. IAM verifies the validity of these credentials before allowing users to access resources.
  • Authorization: IAM authorizes users to perform specific actions on AWS resources. This is done using IAM policies, which are documents that define the permissions that a user or role has. IAM policies specify which AWS resources a user can access and what actions they can perform on those resources.
  • Access Control: IAM allows you to control access to AWS resources by associating IAM policies with users and roles. You can attach one or more IAM policies to a user or role, which determines the permissions that the user or role has.

IAM provides a comprehensive set of features for managing user access, including:

  • Users: Represent individual identities (human and non-human) with unique credentials for accessing AWS resources. IAM users are typically used for long-term access for human users or programmatic access from applications.
  • Roles: Logical entities that define permissions without the need for long-term credentials. Users can assume roles to gain temporary access with specific permissions.
  • Policies: Documents that define the permissions granted to users and roles. Policies specify what actions users can perform on AWS resources and under what conditions.

By leveraging IAM functionalities, you can establish a fine-grained access control system that adheres to the least privilege principle. Here's how IAM features map to the principle:

  • Users and Roles with Defined Permissions: IAM allows you to create users and roles with specific permissions tailored to their job functions. It is possible to connect human IAM users with their corporate identities through the IAM federation.
  • Granular Policy Controls: IAM policies enable you to define precisely what actions users can perform on AWS resources (e.g., read, write, delete). These actions define different access levels in the policy.
  • Conditional Access: IAM policies can be configured with conditions that restrict access based on factors like time of day, IP address, or specific resources.

In the next part of this blog series, we'll delve deeper into the foundations for implementing least privilege with IAM. 

Stay tuned for Part 2: Foundations for Least Privilege with IAM!

Nishant Thorat

Stay Informed

Get the latest updates, news, and exclusive offers delivered to your inbox.

By clicking Sign Up, you agree to our Terms and Conditions.
Thank you! Your submission has been received!
Oops! Something went wrong. Please try again.

Discover Our Featured Blogs

Stay up to date with our informative blog posts.


[Part 1] The Least Privilege Principle and IAM in AWS

The principle of least privilege (PoLP) is easier to understand until you put it into practice. In this series, we will discuss PoLP, how to set up accounts and guardrails, what tools to use, what process to follow, what technical and managerial challenges you may encounter, how to tackle them, and so on.
Nishant Thorat
April 16, 2024
5 min read
User Access Management

Streamlining AWS Access for Growing Startups

As your startup scales on AWS, managing access control becomes crucial. This blog post provides a roadmap for securing your cloud environment. You'll learn about the limitations of basic IAM users, the benefits of centralized identity management, and the capabilities of AWS IAM Identity Center with Just-In-Time access. By the end, you'll have a clear strategy to secure your AWS environment while maintaining agility.
Nishant Thorat
April 15, 2024
5 min read
AWS Cloud

Understanding Instance MetaData Service (IMDS)

Instance metadata service (IMDS) provides sensitive information. Understand IMDSv1 weakness and how IMDSv2 improves security. Identify IMDSv1 enabled instances across your cloud.
Nishant Thorat
February 11, 2024
5 min read