This decision, taken after careful evaluation and reflection, marks the end of a journey embarked upon with ambition and passion to evolve into a self-sustaining Startup.

Despite our commitment and dedication, Noovolari did not achieve the self-sustainability necessary to operate independently from beSharp, our parent company. Over the last year, we have sought investment and explored potential acquisitions to bring Leapp to self-sustainability. Unfortunately, we were unable to secure the necessary support to continue.

This conclusion resulted from a careful analysis of costs and future prospects.

Despite beSharp's ability to support the project, we had set budget and time limits, which were unfortunately exceeded without achieving the desired sustainability.

This choice reflects the harsh reality that, despite the passion that drives our work, the demands of economic sustainability have the upper hand.

Along with the closure of Noovolari, we also announce the termination of all development and commercial activities related to our Leapp Team and Pro products.

We will thank the users who supported our project with a full refund for annual subscriptions.

The Pro and Team versions will remain online until 30 June to facilitate the transition to other solutions. We remain available to assist you with specific needs.

Don't hesitate to get in touch with us at info@noovolari.com

Regarding the open-source project Leapp, we assure you that it will continue to receive support and updates even after the transition to beSharp.

During this period of transition, we are reevaluating how to best continue providing reliable support while adjusting to the new organizational structure. It’s possible that response times may initially be affected as we establish the most efficient processes.

However, please rest assured that our commitment to maintaining and improving Leapp remains steadfast. We appreciate your patience and understanding as we work through these changes.

We want to express our deepest thanks to everyone who believed in Noovolari and Leapp.

Your support and passion have been crucial in this journey.

We aim to keep the open-source project alive by exploring new ways to do so. We hope to continue to count on your support in the next chapter we are about to write.

Thank you all for sharing this journey with us.

The closing of Noovolari is not only the end of a chapter but also an opportunity to learn, grow, and innovate in new directions.

Wish you all the best,

The Noovolari Team

One of our loved customers requests a way to import multiple Leapp sessions simultaneously.

To accommodate this need, we're offering a YAML format for the import functionality. This format provides distinct advantages tailored to different preferences and needs, ensuring a seamless and efficient import process.

Here is an example of a YAML file

sessions:
  - session-1:
      type: "awsIamUserSession"
      awsAccount:
        accountId: "<account-id>"
        accountName: "<account-name>"
      iamUserName: "john.doe"
      accessKey: "<access-key>"
      secretKey: "<secret-key>"
      mfaDevice: "<mfa-device>"
  - session-2:
      type: "awsIamRoleFederatedSession"
      awsAccount:
        accountId: "<account-id>"
        accountName: "<account-name>"
      roleArn: "arn:aws:iam::account:role/developer"
      idpArn: "<idp-arn>"
      samlUrl: "<saml-url>"
  - session-3:
      type: "awsIamRoleChainedSession"
      awsAccount:
        accountId: "<account-id>"
        accountName: "<account-name>"
      roleArn: "<role-arn>"
      assumerSession:
        $ref: "session-1"

🔎 Filter Sessions

We added a filter section on the session page to provide a better user experience.

Now you can filter on the "All Sessions" page by the following search criteria:

• Member: User with whom a Session is shared (from the list of all available Leapp Members).

• Sessions Type: Type of Session present in All Sessions (AWS IAM User, AWS IAM Role Federated, AWS IAM Role Chained, AWS Single Sign-On, etc.)

• Account Name: Filter only for certain accounts (from the list of available accounts)

In addition, there is a "Collapse All/Expand All" button that allows you to view all the accounts in detail with just one click and organize the view more neatly.

Create new Sessions in a more orderly way 🧹

We decided to clean up the form to create a new Leapp Session:

Now, an Alias for each Session is no longer needed.

Also, we improved the way a user can select the Assumer Session for an AWS Role Chained

This feature lets you streamline your workflow by creating sessions without useless parameters!

🐞 Bug Fixing

• ⚙️ When you used to import a Leapp Team session on the Desktop App, the default region was always AF-South-1. Thanks to Ricky, now the default region is based on the region set by the user in the settings.

• 🔗 Restored Dynamic Assumer functionality for IAM chained sessions. Thanks, Eric for resolving this bug!

But wait, there's more.

This Release note will be a bi-weekly update on the Noovolari news. Stay updated here

We'll see you very soon,

Your friends at Noovolari

---

P.S. We're actively looking for funding; contact us at info@noovolari.com for inquiries

No more digging through heaps of sessions.

Now, your sessions are neatly tucked away in their dedicated account folders. Finding sessions is now as simple as finding your favorite socks! Just browse through the account folders, and voila!

Fresh out of the oven!

Integration detail is more comprehensive.

We added a general info section in the integration detail to provide a more comprehensive overview.

Now, at a glance, you can access essential information about the integration, including:

• AWS Identity Center Portal

• AWS Instance Arn

• AWS Account ID

Import and deletion of AWS Identity Center Users

Now, you can add additional Leapp Members directly from your AWS Identity Center Users.

Welcome Warp!

We've added a new terminal to Leapp, specially tailored for all MacOS enthusiasts! This feature comes from one of our community rockstars. Thanks, Blyzer!

Warp is a modern, Rust-based terminal with AI built in so you and your team can build great software, faster.

🐞 Bug Fixing

• 🌎 In the Leapp Team, now it is possible to enable multi-region for the integration setup. Thanks, Alex!

• ⚙️ Thanks Eric! In the Leapp Team, we fixed a bug that prevented retrieving users from an integration when using an alias in the portal URL of the AWS IAM Identity Center.

• 🙋‍♂️ In the Leapp Team, there was a bug with Leapp groups. Now, all the relevant Sessions are automatically shared by adding a new Member to a group. Thanks, Riky!

But wait, there's more.

This Release note will be a bi-weekly update on the Noovolari news. Stay updated here

We'll see you very soon,

Your friends at Noovolari

---

P.S. We're actively looking for funding; contact us at info@noovolari.com for inquiries

PiedPiper company is a startup working on the AWS Cloud ecosystem. Like many others, it has adopted a Landing Zone approach in collecting and governing different AWS Accounts, each with a specific purpose.

PiedPiper has different developers, and each must operate in one or more accounts. Let’s see how PiedPiper leveraged some best practices to do so.

Let’s meet Bertram!

Bertram, like many other developers in PiedPiper, must at first identify himself in the cloud he has to operate. From many options, PiedPiper opted for the SAML 2.0 AWS IAM Federated Access approach

SAML 2.0 Federated Access is the way PiedPiper company identifies Bertram in its Cloud Identity Provider, and in general, Identity federation is a system of trust between two parties for the purpose of authenticating users and conveying the information needed to authorize their access to resources.

In this system, the identity provider (IdP) is responsible for user authentication, and a service provider (AWS) controls resource access.

A Federated Access through SAML 2.0 translates into an AWS IAM Role, which we call an IAM Role Hatbox

The IAM Roles Hatbox account

PiedPiper has adopted the Leapp suggested way to control and grant permissions to operate in different accounts while completely isolating the access account and defining a one-on-one relationship between the IdP Identity of the developer and its identity on AWS.

The trust relationship policy in AWS guarantees this trust:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::12345678910:saml-provider/Gsuite_PiedPiper"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "<https://signin.aws.amazon.com/saml>"
                }
            }
        }
    ]
}

To do that, PiedPiper created a single AWS account with the sole purpose of managing User access.

This AWS account (Aka: IAM Account) contains only IAM Roles that we call Hatbox IAM Roles, which can only do cross-account access, as shown in the picture.

A Hatbox IAM Roles is similar to a Hatbox, in which every hat represents a different role a developer can assume in an AWS Account, using the STS assume-role operation in AWS.

Every developer, Bertram included, has a nominal (name.surname) IAM Role whose policy only grants the assuming role to one or more specific AWS accounts each developer has to operate into.

Every IAM Hatbox Role will have a policy like the one for Bertram:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::98765432101:role/developer-only"
    }
  ]
}

This strategy can be adopted for one or more AWS Accounts, Internal or External to an AWS Organization. One of the immediate advantages is that it is simpler to isolate a developer's scope in the Cloud environment.

Managing IAM Roles at scale with the Leapp Team

PiedPiper uses the Leapp Team to manage its Developers’ accounts, and to do so, let’s see how Richards can access one account it must operate into.

At first, PiedPiper has created two Leapp Team Sessions:

• The Nominal Hatbox Session (where Bertram CAN ACCESS)

• The IAM Role Chained session that Bertram must assume. (what Bertram CAN OPERATE.)

To take advantage of Leapp Team's dynamic session feature, PiedPiper created an IAM Federated Role Session with the alias bertram.gilfoyle.

The dynamic parameter feature

PiedPiper uses the dynamic feature to simplify sharing the Chained IAM Role with different developers. By using a name.surname pattern, it is possible to separate the final Role from every developer in the AWS Organization.

The company needs to create distinct hatbox IAM Roles, and the Leapp Team can effortlessly convert the final Role into an operational one by replacing the pattern with the actual name and surname of each developer. This streamlined process emphasizes simplicity.

A single dynamic IAM Role Chained Session can be shared among as many developers as possible. The advantage here is clear: a company has the flexibility to manage and segregate account access in both directions; it can sever the entire account access to every developer by removing the chained role, or it can add/remove access to single developers using the Hatbox strategy.

By following what we described before, PiedPiper created a new IAM Role Chained Session, specifying the default dynamic pattern as the Assumer.

PiedPiper now only needs to share these two sessions with Bertram to make him able to work in the destination account.

What is done for one it is done for many.

Bertram is only one of many different developers in the PiedPieper company, and what we have seen for him can be easily extended for everyone in the company by following the same rules as shown before.

What about Bertram?

Bertram can now operate in the destination account by logging into the Leapp Desktop App using his team credentials, and what happens is that a new Assumable Role Session is available to him; Leapp Team has converted the dynamic pattern to a valid IAM Role that identifies Bertram explicitly.

Bertram has one AWS IAM Federated Role, which is personal and shared only with him. The AWS Chained Session is, instead, shared with all the developers in the company; this way, PiedPiper has complete control over sharing/unsharing with Bertram and his colleagues.

Finally, Bertram can use these Leapp Sessions to access the correct AWS Account he needs to work into.

* The operations applied in the Leapp Team must reflect configurations already defined in AWS, e.g., having the correct assume role policies and the correct Hatbox IAM Roles defined in the IAM Account. Leapp Team helps you define a proper method, while in the future, we will also provide an automatic procedure to synchronize your Company’s dashboard with your AWS Organization.

PiedPiper company is a startup working on the AWS Cloud ecosystem. Like many others, it has adopted a Landing Zone approach in collecting and governing different AWS Accounts, each with a specific purpose.

PiedPiper has different developers, and each must operate in one or more accounts. Let’s see how PiedPiper leveraged some best practices to do so.

Let’s meet Richard!

Richard, like many other developers in PiedPiper, must at first identify himself in the cloud he has to operate. From many options, PiedPiper opted for the AWS IAM User approach.

An AWS IAM User is the way PiedPiper company identifies Richard in its Cloud environment, and this particular IAM User is called an IAM User Hatbox.

The IAM Users Hatbox account

PiedPiper has adopted the Leapp suggested way to control and grant permissions to operate in different accounts while completely isolating the access account. To do that, PiedPiper created a single AWS account with the sole purpose of managing User access.

This AWS account (Aka: IAM Account) contains only IAM Users that we call Hatbox IAM Users, which can only do cross-account access, as shown in the picture.

A Hatbox IAM USER is similar to a Hatbox, in which every hat represents a different role a developer can assume in an AWS Account, using the STS assume-role operation in AWS.

Every developer, Richard included, has a nominal (name.surname) IAM user whose policy only grants assuming role to one or more specific AWS accounts each developer has to operate into.

Every IAM Hatbox user will have a policy like the one for Richard:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::98765432101:role/developer-only"
    }
  ]
}

This strategy can be adopted for one or more AWS Accounts, Internal or External to an AWS Organization. One of the immediate advantages is that it is simpler to isolate a developer's scope in the Cloud environment.

Managing IAM User at scale with Leapp Team

PiedPiper uses the Leapp Team to manage its Developers’ accounts, and to do so, let’s see how Richards can access one account it must operate into.

At first, PiedPiper has created two Leapp Team Sessions:

• The Nominal Hatbox Session (where Richard CAN ACCESS)

• The IAM Role Chained session that Richard must assume. (what Richard CAN OPERATE.)

To take advantage of Leapp Team's dynamic session feature, PiedPiper created an IAM User Session with the alias richard.henricks.

The dynamic parameter feature

PiedPiper uses the dynamic feature to simplify sharing the Chained IAM Role with different developers. By using a name.surname pattern, it is possible to separate the final Role from every developer in the AWS Organization.

The company needs to create distinct hatbox IAM users, and the Leapp Team can effortlessly convert the final Role into an operational one by replacing the pattern with the actual name and surname of each developer. This streamlined process emphasizes simplicity.

A single dynamic IAM Role Chained Session can be shared among as many developers as needed. The advantage here is clear: a company has the flexibility to manage and segregate account access in both directions; it can sever the entire account access to every developer by removing the chained role or add/remove access to single developers using the Hatbox strategy.

By following what we described before, PiedPiper created a new IAM Role Chained Session, specifying the default dynamic pattern as the Assumer.

PiedPiper now only needs to share these two sessions with Richard to make him able to work in the destination account.

What is done for one it is done for many.

Richard is only one of many different developers in PiedPiper company, and what we have seen for him can be easily extended to everyone in the company by following the same rules as shown before.

What about Richard?

Richard can now operate in the destination account by logging into the Leapp Desktop App using his team credentials, and what happens is that a new Assumable Role Session is available to him; the Leapp Team has converted the dynamic pattern to a valid IAM Role that identifies Richard explicitly.

Richard has one IAM User, which is personal and shared only with him. The AWS Chained Session is, instead, shared with all the developers in the company; this way, PiedPiper has complete control over sharing/unsharing with Richard and his colleagues.

Finally, Richard can use these Sessions to access the correct AWS Account he needs to work into.

* The operations applied in the Leapp Team must reflect configurations already defined in AWS, e.g., having the correct assume role policies and the correct Hatbox IAM Users defined in the IAM Account. Leapp Team helps you define a proper method, while in the future, we will also provide an automatic procedure to synchronize your Company’s dashboard with your AWS Organization.

We understand how challenging it can be to manage access in the constantly evolving world of cloud computing. It can take up so much time and effort, and we know how crucial it is to ensure that teams have smooth, secure, and efficient access.

Leapp isn't just a product; it represents our vision to simplify cloud access for everyone. We know how important collaboration is in today's fast-paced digital world. But we also know that tools must be efficient and secure to collaborate. That's why we've created Leapp, and we are now launching Leapp Team - a platform that will revolutionize how teams interact with cloud environments, making the process smoother, more secure, and inherently collaborative.

Decentralization in Cloud Computing: Unlocking Efficiency and Empowerment

In our journey through the cloud computing landscape, we've encountered a common pattern: the reliance on a delegation model. Traditionally, a select few hold the reins of cloud access, embodying a centralized approach that, while stable, often stifles the very essence of creativity and agility in a team.

Though rooted in a desire for control and oversight, this approach inadvertently creates bottlenecks. It places immense pressure on a few 'gatekeepers' and leaves team members in a constant wait for access permissions - a scenario far from ideal in today's fast-paced work environments.

But we asked ourselves, "What if there's a better way?", “What if we embrace the spirit of collaboration and empowerment that thrives in the open-source community instead of centralizing?” This thought led us to a groundbreaking idea: decentralization.

Decentralization in cloud access isn't just a strategy; it's a shift towards a more democratic, empowering work culture. It's about giving every team member the keys to their part of the Cloud kingdom within a secure and structured environment. This approach creates a dynamic, responsive atmosphere where everyone has timely access to what they need, fostering a sense of ownership and responsibility.

The beauty of decentralization lies in its ability to streamline operations and enhance security. This is our response to the limitations of the delegation model in cloud computing, and we have seen that by embracing this model, organizations can unlock greater efficiency, agility, and innovation in their cloud operations.

Reimagining Cloud Access: A User-Centric Approach

At Noovolari, we're driven by a simple yet profound belief: technology should empower, not hinder. We've been trying to find harmony in the intricate usage of cloud computing, where security and ease of use often seem at odds. We aim to create an environment that safeguards your work without adding complexity.

We've all been tangled in the web of cloud access management, feeling more like we're battling a maze rather than harnessing a tool. We understand how this frustration can overshadow the true potential of cloud computing. But more importantly, we see a path forward, a way to transform this experience into something empowering and fluid.

Leapp is the embodiment of this vision. It's where we put the user - you, the developers, the innovators - at the heart of everything. Our interfaces and workflows are crafted not just for functionality but for intuitiveness and ease. With Leapp, we're ensuring that your time is spent on what truly adds value to your work, surrounded by security that feels as natural as it is robust.

We firmly believe that access management is a pivotal element of user-centric design. It's why we've reimagined access controls to be more intuitive, reducing the mental load and turning what used to be a barrier into a gateway. Accessing the resources you need is now quick, smooth, and hassle-free, removing the friction that often clouds the day.

Enhancing Functionality Through Integrations

While current solutions have set a standard in cloud access management, their approach often leans towards centralized control and one-size-fits-all frameworks that may not align with the unique needs of every organization. Teams can be constrained by inflexible workflows and a lack of adaptability, particularly in dynamic environments where quick access adjustments are crucial.

In Leapp Team, integrations mean more than just linking systems; they enhance how these systems work together. By integrating with platforms like AWS Identity Center, we're not just accessing their services but combining them with Leapp's unique capabilities. This approach doesn't only connect systems; it enhances them, creating a seamless and powerful experience.

Temporary Access for Dynamic Security

In our ongoing development of Leapp Team, a key focus is on implementing temporary access within AWS Identity Center. This feature, critical for dynamic security, is also designed with the principle of least privilege in mind. It ensures that access rights are granted on a need-to-use basis and for the minimum time necessary, significantly enhancing security.

The temporary access feature will allow administrators to assign access permissions for a specific duration, aligning perfectly with situations where access requirements are transient. This approach minimizes security risks by limiting long-term access and adheres to the best practices of least privilege, ensuring that users have access only when absolutely necessary and for no longer than needed.

This feature will provide a robust mechanism to manage permissions more securely and effectively, embodying our commitment to creating a safer, more agile cloud environment.

Building Decentralized Access Requests and Approvals

Another core enhancement we are developing for AWS Identity Center is decentralized access through requests and approvals. Moving away from traditional centralized management, this feature will allow for a more agile and distributed approach to access management. Our goal is to empower individual team members to manage access requests and approvals autonomously, enhancing the process's speed, flexibility, and responsiveness. This enhancement is designed to seamlessly integrate with AWS Identity Center's existing security framework, offering a more dynamic approach to access management.

Working on Enhanced Visibility into AWS Environments

We are also in the process of integrating visibility schemas into AWS Identity Center via Leapp Team. This feature, once completed, will provide a detailed and user-friendly view of access points within AWS environments. The aim is to make navigating the complex world of permissions and access rights simpler and more intuitive, thereby improving management efficiency and aiding in maintaining compliance with security standards.

Conclusion: Elevating Current Solutions with Advanced Capabilities

By integrating these advanced features into Integrations, Leapp Team is setting new standards in cloud access management. Decentralized access, temporary permissions, and enhanced visibility are not just features – they represent a holistic approach to managing cloud environments. With Leapp Team, users can now enjoy a more secure, flexible, and user-friendly experience tailored to meet the needs of modern, dynamic cloud teams.

What is an IAM User?

When you create your first AWS account, you sign in with an identity that has full access to all the services and resources in your account. That identity is called the AWS account root user. As soon as you log into the AWS Console with the AWS account root user, you’ve to find a safer pattern to access it. Why? Because credentials associated with the AWS account root user are not disposable; in case of credentials theft, there is no way to invalidate them. That said, you can implement a safer access pattern by creating an IAM Identity called IAM User.

An AWS Identity and Access Management (IAM) user is an entity that you create in AWS. The IAM user represents the human user or workload who uses the IAM user to interact with AWS. A user in AWS consists of a name and credentials.

A brand-new IAM User has, by default, no permissions. To allow an IAM User to access services and resources in the AWS account in which it was created, you’ve to assign an IAM Policy and one or more credentials to it.

As explained in this article by my fellow colleague Alessandro Gaggia, an IAM Policy is a document that allows you to specify what an IAM Identity (in this case, an IAM User) can do on which resources or services, under what conditions. An IAM Policy is not enough to enable the IAM User permission to access resources or services; credentials must be associated with it.

Based on the way you want to access AWS, you have to use different kinds of credentials.

If you want to enable the IAM User to access the AWS Console, you’ve to assign a console password to the IAM User. The IAM User console password cannot be used to access AWS resources or services from the CLI or SDK.

Access to services or resources from the CLI or SDK is called programmatic access. To grant the IAM User programmatic access, you’ve to set up Access Keys; Access Keys that are created and assigned to an IAM User are long-term credentials. It means they’ve no expiration; you can use them to access your AWS account until they’re disabled or deleted. A common best practice to avoid long-term credentials is to rotate IAM User’s Access Keys periodically by deleting the old ones and replacing them with new ones created from scratch. In addition, IAM User Access Keys can be used to generate temporary credentials through the AWS Security Token Service GetSessionToken API.

Another important common best practice consists in requiring multi-factor authentication for all IAM users in your account. With MFA, users must provide two forms of identification: a console password or Access Keys, and a temporary numeric code that's generated on a hardware device or by an application on a smartphone, like Google Authenticator.

IAM Users are an effective instrument if you want to enable a human or application to access resources and services in a specific account, i.e. the one in which the IAM Users lives. But, there are many use cases that go beyond the possibilities of an IAM User. In particular, an IAM User does not fit a scenario in which we need to grant temporary permissions to trusted entities without sharing long-term credentials. Those trusted entities could be outside the boundary of my account (supposed that I have a single one), outside the boundary of AWS, or outside the boundary of my company.

At this point, you may wonder what kind of technology you can exploit to overcome these limits.

When it comes to granting temporary permissions to trusted entities without sharing long-term credentials, the IAM Identity that comes to the rescue is called IAM Role.

IAM Role

An IAM Role is an Identity that you create in your AWS Account. Like an IAM User, an IAM Role has permissions defined in one or more IAM Access Policies associated with it. But, instead of being associated with one person or application, a Role is designed to be assumed by trusted entities. Assuming an IAM Role means generating temporary credentials associated with that IAM Role. These credentials allow us to perform operations against resources or services based on the permissions defined in the IAM Access Policy associated with the IAM Role.

You can define which trusted entities are allowed to assume the role and acquire temporary security credentials using a Trust Policy for an IAM Role. In addition, the trust policy of a role defines the conditions under which the role can be assumed. The trust policy is written in JSON format and is attached to the role.

Here's an example of what a trust policy for an IAM role might look like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::YOUR_ACCOUNT_ID:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Replace YOUR_ACCOUNT_ID with your actual AWS account ID. In this trust policy, the Principal is set to the root user of the same AWS account (arn:aws:iam::YOUR_ACCOUNT_ID:root). This means that any entity within the account can assume the role.

Please note that while this example demonstrates granting access to any entity within the account, it's important to follow the principle of least privilege. Granting such broad permissions should be done with caution, as it might lead to unintended access and security risks. It's generally recommended to define more specific trust policies that only allow trusted entities that actually need the permissions provided by the role to assume it. It's important to craft trust policies carefully; trust policies, along with the permissions policies attached to the role, play a crucial role in controlling access to AWS resources in a secure and controlled manner.

Let’s deepen some access scenarios in which I can use IAM Roles to grant temporary permissions to trusted entities.

Federated Access from External Identity Provider (IdP)

In some organizations, user identities are managed outside of AWS using an Identity Provider (IdP). To provide users with access to AWS resources, you can enable federated access. This allows users authenticated by the external IdP to access your AWS environment without needing to create IAM Users. Instead, they're granted temporary access using security tokens based on their IdP authentication. This enhances security and reduces the need for separate user accounts in AWS. There are different kinds of federated access protocol, based on the IdP you’re using.

SAML Federated Access

SAML (Security Assertion Markup Language) is a widely used protocol for SSO. When a user from your organization tries to access AWS resources, they authenticate with your external SAML-compatible IdP (such as Microsoft Active Directory Federation Services or Okta). After successful authentication, the IdP generates a SAML assertion, which is a digitally signed document containing the user's identity and attributes.

The SAML assertion is passed to AWS through the AssumeRoleWithSAML API call. This API call includes the Amazon Resource Name (ARN) of the IAM role the user wants to assume, along with the SAML assertion. AWS verifies the SAML assertion's signature and attributes with the trusted IdP metadata.

If everything checks out, AWS issues temporary security credentials associated with the IAM role specified in the request. These credentials enable the user to access AWS services and resources according to the permissions defined in the IAM role's policies.

OpenID Connect Federated Access

OpenID Connect (OIDC) is a modern protocol built on top of OAuth 2.0 that allows applications to authenticate users. When users want to access AWS resources, they authenticate with their OpenID Connect-compatible IdP. The IdP returns an ID token, which contains the user's identity and other relevant information.

To enable federated access in AWS, you create an IAM identity provider that points to your OIDC IdP. Then, you create an IAM role with a trust policy that allows the OIDC identity provider to assume the role. Users initiate federated access by signing in through the IdP, and the OIDC token is exchanged for temporary AWS credentials through the AssumeRoleWithWebIdentity API call.

Web Identity Federated Access

Web identity providers include well-known platforms like Amazon, Facebook, Google, and more. These providers offer their own authentication mechanisms for user sign-ins. When a user authenticates with one of these providers, they receive an identity token.

Similar to OIDC, you establish an IAM identity provider for the web identity provider. You create an IAM role with a trust policy allowing the web identity provider to assume the role. Users authenticated by the web identity provider can assume the role using the AssumeRoleWithWebIdentity API call, receiving temporary AWS credentials to access resources based on the role's permissions.

Cross-Account Access

Traditionally, managing access to resources across different AWS accounts could be complex and potentially compromise security by sharing long-term credentials. However, AWS cross-account access with IAM roles simplifies this process while enhancing security and control. It empowers organizations to collaborate seamlessly, allowing users from one AWS account to access resources in another account with well-defined permissions.

This capability is particularly valuable for scenarios such as:

• Organizational Collaboration: different departments, teams, or external partners can work together effectively by granting controlled access to specific resources.

• Managed Services: organizations can centralize operations by providing external services, like managed security or analytics, and secure access to resources.

• Consulting and Vendor Engagement: consulting companies or vendors can access client resources while adhering to stringent security practices.

The core concept behind AWS cross-account access is the utilization of IAM roles. Instead of sharing credentials, a trusted relationship is established between accounts. The trusting account defines an IAM role with a Trust Policy that allows IAM Identities in the trusted account to assume that role.

Let's say Account A (123456789012) wants to allow users from Account B (987654321001) to access specific resources. Account A creates an IAM role named CrossAccountRoleA and attaches a Trust Policy that specifies that Account B is allowed to assume this role.

Trust Policy for CrossAccountRoleA in Account A:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321001:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

In Account B (987654321001), IAM users or roles can assume the CrossAccountRoleA role from Account A (123456789012) because Account A has defined a trust policy allowing it. Users in Account B can use the AssumeRole API call to acquire temporary credentials for the CrossAccountRoleA role.

Assuming CrossAccountRoleA in Account B using AWS CLI:

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/CrossAccountRoleA --role-session-name MySession

This will return temporary security credentials that can be used to access resources in Account A.

AWS Service-to-Service Access

AWS services often need to interact with each other for various purposes. For example, you might want an AWS Lambda function to access data stored in Amazon S3. Instead of relying on long-term credentials, you can create an IAM role with the required permissions and allow the Lambda function to assume that role. This enables the Lambda function to securely access the necessary resources without exposing sensitive credentials.

Here's a concise breakdown of how AWS Service-to-Service Access works:

1. Role Creation: create an IAM role with necessary permissions for an AWS service to perform specific actions on other AWS resources.

2. Trust Policy: specify the AWS service's ARN in the role's trust policy, allowing it to assume the role.

3. Role Assumption: the AWS service requests temporary credentials from AWS STS by assuming the role.

4. Temporary Credentials: AWS STS provides temporary credentials, including the Access Key ID, the Secret Access Key, and the Session Token.

5. Resource Access: the AWS service uses temporary credentials to interact securely with other AWS resources.

EC2 Instance Access without Long-Term Credentials

On 12 June 2014, Mike Pope announced a new, crucial AWS feature: Granting Permission to Launch EC2 Instances with IAM Roles.

If you deploy a workload on an EC2 instance that requires access to AWS services, instead of embedding IAM User’s long-term credentials (Access Keys) directly into the instance, which can pose security risks, you can assign an IAM role to it. This role grants temporary permissions to the EC2 instance, ensuring that the workload running on this instance can interact with AWS services securely without exposing credentials. This dynamic and controlled approach simplifies management and enhances security.

When creating the IAM Role that has to be attached to the EC2 instance, remember to add a Trust Policy that allows the trusted entity (in this case, the EC2 service) to assume the role. In particular, you’ve to add "Service": "ec2.amazonaws.com" as the Principal in the Trust Policy.

The IAM Role can be attached to the instance during its creation or when it is already running.

When you assign an IAM role to an EC2 instance, an instance profile is automatically created. This instance profile is associated with the IAM role and acts as a container for temporary security credentials. The instance profile is managed by AWS and is not directly accessible from outside the instance.

When an application or process running on the EC2 instance needs to access AWS services, it makes an HTTP request to the metadata service, which is a web service that provides information about the instance's configuration and attributes. In this case, the http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> endpoint is invoked to retrieve temporary security credentials associated with the IAM role. These credentials include an Access Key ID, a Secret Access Key, a Session Token, and an Expiration Time. EC2 instances automatically renew the temporary credentials by periodically requesting updated credentials from the metadata service. This ensures uninterrupted access to AWS resources.

Interaction between IAM Users and IAM Roles

As far as now, we didn’t take into account any possible interaction between IAM Users and IAM Roles. Well, IAM users can interact with IAM roles through the process of assuming roles. This allows IAM users to temporarily take on the permissions and privileges associated with an IAM role, granting them access to resources they might not have direct permissions. This interaction is commonly used to delegate access to specific resources without sharing long-term credentials.

An IAM User initiates the process by calling the AssumeRole API, specifying the ARN (Amazon Resource Name) of the IAM Role they want to assume. The IAM User must have the necessary permissions to assume the role in the first place. These permissions are defined by an IAM Access Policy attached to the user. The IAM Role’s Trust Policy must contain a statement that allows the IAM User to assume it. If the trust policy allows the IAM User to assume the role, AWS STS (Security Token Service) generates temporary credentials for the IAM User. The IAM User can use the temporary credentials to make requests to AWS services just like they would with their own IAM User credentials. The IAM User only has the permissions associated with the assumed role, not their original IAM User permissions.

As previously mentioned, it is possible to enable MFA for an IAM User. In the user's Access Policy, you can define actions that require MFA protection. This means that these actions can only be performed using IAM User credentials that include MFA information.

To generate credentials that include MFA information, you must call the STS GetSessionToken API and provide a valid MFA token associated with a hardware or virtual MFA device. You can then use the resulting credentials to call MFA-protected actions.

When should I go for IAM Users and when for IAM Roles?

IAM Users

IAM Users are well-suited for managing access within your AWS account, particularly for individuals and applications that require straightforward access to AWS services and resources. They offer personalized access control and are appropriate for the following scenarios:

• Individuals: If you have human users who need to interact with AWS services using the AWS Management Console, IAM Users provide a way to grant personalized access. You can assign permissions based on each user's roles and responsibilities.

• Simple Application Access: For applications running within your AWS account that require programmatic access to AWS services, IAM Users can be used. However, it's important to note that IAM Roles are often a better choice for applications, as they provide temporary access without exposing long-term credentials.

While IAM Users are useful for straightforward access requirements, they might not be the optimal solution for scenarios involving temporary access, cross-account access, or enhanced security.

IAM Roles

IAM Roles offer a more comprehensive approach to access management, particularly when dealing with complex access patterns and security considerations. They are the recommended choice in the following situations:

• Federated Access: When you need to grant temporary access to users from external identity providers (IdPs) such as SAML, OpenID Connect, or web identity providers, IAM Roles provide a secure way to authenticate and access AWS resources without exposing long-term credentials.

• Cross-Account Access: IAM Roles excel at enabling secure collaboration between AWS accounts. This is crucial for scenarios like organizational partnerships, managed services, and consulting engagements.

• Service-to-Service Access: IAM Roles facilitate secure interactions between AWS services without relying on long-term credentials. This enhances security and adheres to the principle of least privilege.

IAM Roles streamline security, minimize long-term credential exposure, and provide controlled access. They're designed to address a wide range of security and access requirements.

In summary, while IAM Users are suitable for simpler access scenarios within an AWS account, IAM Roles offer a more advanced and secure approach for managing complex access patterns, temporary access needs, and cross-account collaboration. The choice between IAM Users and IAM Roles should align with the specific security requirements and complexity of the access scenario you're addressing.

That’s all Folks!

In this blog post we have seen what are IAM Users and IAM Roles, what are the differences between them, and the use cases in which they’re used.

I hope you enjoyed this blog post and that you find it informative. Please, don’t hesitate to provide your feedback and share your thoughts about the topic. Feel free to reach out to us on our Community Slack!

Stay tuned for new publications!

This article will provide examples of both roles and policies and explains how they relate to IAM roles, users, and groups.

By the end, you will have a clear understanding of IAM within AWS and be better equipped to manage access and identity needs on the platform.

What is an IAM Policy in AWS?

An IAM policy is a document that defines permissions for AWS resources. It is an essential component of AWS identity and access management (IAM) that provides fine-grained control over who can access specific resources in your AWS account.

IAM policies are used to grant or deny access to AWS resources such as Amazon S3 buckets, EC2 instances, and RDS databases.

IAM policies are written in JSON format and consist of one or more statements. Each statement contains a set of permissions for a specific resource or set of resources. For example, you might use an IAM policy to grant read-only access to a particular S3 bucket, or to allow a user to start and stop an EC2 instance.

Elements of an IAM Policy

An IAM policy is comprised of the following main elements:

Version

The Version element specifies the version of the IAM policy language used in the policy.

The current version of the policy language is October 17, 2012.

Example:

{
    "Version": "2012-10-17",
    ...
}

Statement

The Statement element is a list of one or more statements that define the permissions for the policy.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            ...
        },
        {
            ...
        }
    ]
}

Effect

The Effect element specifies whether the statement allows or denies access to the resource.

The values for Effect are Allow and Deny.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            ...
        },
        {
            "Effect": "Deny",
            ...
        }
    ]
}

Action

The Action element specifies the specific actions that are allowed or denied for the resource.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            ...
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            ...
        }
    ]
}

Resource

The Resource element specifies the AWS resource that the policy applies to.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*",
            ...
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "*",
            ...
        }
    ]
}

Principal

The Principal element specifies the entity that the policy applies to.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:user/Bob",
                    "arn:aws:iam::123456789012:role/DevOps"
                ]
            },
            ...
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "*",
            "Principal": "*",
            ...
        }
    ]
}

What is an IAM Role in AWS?

An IAM role is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.

IAM roles are similar to IAM users, but with some important differences.

IAM roles are not associated with a specific user or group. Instead, they are intended to be assumed by anyone who needs the permissions associated with the role.

IAM roles are a way to delegate access to AWS resources without the need to create and manage long-term AWS credentials.

For example, you might create an IAM role that grants access to an S3 bucket, and then allow a Lambda function to assume that role when it needs to access the bucket.

This way, you don't need to manage access keys for the Lambda function, and you can maintain tighter control over who has access to the S3 bucket.

Main Elements of an IAM Role

Assuming an AWS IAM Role

Assuming an AWS IAM Role means temporarily taking on the permissions and policies associated with that role. This is done by using the AWS Security Token Service (STS) API to obtain temporary security credentials, which include an access key, a secret access key, and a security token.

The user who is assuming the role must have permission to do so, which is granted by the role's trust policy. The trust policy specifies which users or services are allowed to assume the role.

There are several ways to assume an IAM Role in AWS, including using the AWS Management Console, AWS CLI, AWS SDKs, and the AssumeRole API.

When using the AssumeRole API, the user must provide their own security credentials and the ARN of the role they want to assume. The API then returns temporary security credentials that can be used to access AWS resources associated with the role.

Once the user has obtained temporary security credentials, they can use them to access AWS resources associated with the role until the credentials expire. The length of time that the credentials are valid can be set in the role's session duration policy. By default, this is set to one hour but can be increased up to 12 hours.

How is an IAM Policy different from an IAM Role?

An IAM policy and an IAM role are both used to control access to AWS resources. However, they serve different purposes.

An IAM policy is used to define permissions for a specific AWS resource or set of resources. It is attached to a user, group, or role to grant or deny access to those resources.

IAM policies are static and do not change based on the user, group, or role that is accessing the resources.

In contrast, an IAM role is a set of permissions that can be assumed by a user, group, or service.

It is a way to delegate access to AWS resources without the need to share long-term security credentials such as access keys.

When a user (or a service) assumes an IAM role, they inherit the permissions associated with the role. IAM roles are dynamic (opposed to policies) and can change based on the user, group, or service that is assuming the role.

IAM roles are useful for scenarios where you need to grant temporary access to a resource.

For example, you might have a script that needs to access an S3 bucket to upload a file. Instead of embedding AWS credentials in the script, you can create an IAM role that has permission to access the S3 bucket and then assume that role in the script.

Examples of IAM Policies

Here are some examples of simple IAM policies for common use cases:

Allow read-only access to an S3 bucket

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}

This policy allows a user to read objects from the example-bucket S3 bucket and list the contents of the bucket, but does not allow them to upload or modify objects.

Allow full access to an EC2 instance

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*"
        }
    ]
}

This policy allows a user to perform any action on any EC2 instance in the account.

Allow read-only access to an RDS instance

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBSnapshots",
                "rds:DownloadDBLogFilePortion"
            ],
            "Resource": [
                "arn:aws:rds:us-west-2:123456789012:db:mysql-db",
                "arn:aws:rds:us-west-2:123456789012:snapshot:mysql-db-snapshot"
            ]
        }
    ]
}

This policy allows a user to view information about the mysql-db RDS instance and download log files, but does not allow them to perform any modifications.

Allow read-only access to an SQS queue

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueUrl",
                "sqs:ReceiveMessage"
            ],
            "Resource": "arn:aws:sqs:us-west-2:123456789012:example-queue"
        }
    ]
}

This policy allows a user to retrieve the URL of the example-queue SQS queue and receive messages from the queue, but does not allow them to send messages or modify the queue in any way.

Allow read-only access to a DynamoDB table

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeTable",
                "dynamodb:GetItem",
                "dynamodb:Query",
                "dynamodb:Scan"
            ],
            "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/example-table"
        }
    ]
}

This policy allows a user to view the schema of the example-table DynamoDB table and read items from the table, but does not allow them to modify the table in any way.

Increase AWS Security Posture with IAM Roles and Policies

Using a combination of IAM roles and policies is an effective way to increase the security posture of an AWS account. Here are some best practices to follow:

Use Least Privilege

When creating IAM policies, it's important to use the principle of least privilege. This means granting users and roles only the permissions they need to perform their job functions and no more.

For example, if a user only needs read access to an S3 bucket, don't grant them write or delete access.

Rotate Credentials

AWS recommends regularly rotating access keys and secret access keys for IAM users and roles. This helps to reduce the risk of unauthorized access to your resources in the event that credentials are compromised.

Use IAM Roles Instead of Access Keys

IAM roles are a more secure way to grant temporary access to AWS resources than using access keys.

When a user assumes an IAM role, they get temporary security credentials that expire after a specified amount of time. This minimizes the risk of credentials being compromised and reduces the need to manage long-term access keys.

Use Managed Policies

AWS provides a number of managed policies that can be used to grant permissions to users and roles.

These policies are created and maintained by AWS and are designed to follow best practices for security and compliance.

By using managed policies, you can be sure that your users and roles have the appropriate permissions without having to create and maintain policies yourself.

Use Conditions in IAM Policies

IAM policies can include conditions that further restrict the permissions granted to users and roles.

For example, you can create a policy that only allows access to a resource during certain hours of the day or only from certain IP addresses.

Using conditions can help to further reduce the risk of unauthorized access to your resources.

Use Multi-Factor Authentication (MFA)

Enabling multi-factor authentication (MFA) for IAM roles is an effective way to increase the security of your AWS account.

MFA requires users to provide a second form of authentication, such as a hardware token or a mobile app, in addition to their password.

This makes it much more difficult for an attacker to gain unauthorized access to your resources even if they have obtained the user's password.

By following these best practices, you can significantly increase the security posture of your AWS account and better protect your resources from unauthorized access.

What have we seen

In this article, we explored the differences and similarities between IAM roles and policies in AWS.

IAM policies define permissions for AWS resources and are used to grant or deny access to specific resources in your AWS account.

IAM roles, on the other hand, are AWS identities with permission policies that determine what the identity can and cannot do in AWS. IAM roles are a way to delegate access to AWS resources without the need to create and manage long-term AWS credentials.

We also discussed the main elements of an IAM policy, including the version, statement, effect, action, resource, and principal. Additionally, we explained how to assume an IAM role in AWS using the AWS Security Token Service (STS) API.

To increase the security posture of an AWS account, we recommended using a combination of IAM roles and policies and following best practices such as using least privilege, rotating credentials, using managed policies, using conditions in IAM policies, and enabling multi-factor authentication (MFA) for IAM roles.

Overall, by understanding the differences between IAM roles and policies and following best practices, you will be better equipped to manage access and identity needs on the AWS platform.

I really hope that this little article has been of help for all of you, and as always, feel free to comment and reach us on our community slack.

Until next time, stay safe and see you in the next article, in which we’ll discuss about IAM Users and Groups! 😉

You may have seen it in our desktop application, so “What is this?” should have already popped into your mind; if not, you’ll learn about this today… surprise! 😄

Workspaces are, as the name implies, logically separated environments where all Leapp access and configurations live. It contains all the relevant information about your Sessions, your Leapp setup, and your Plugins, so in simple terms, everything that is needed for Leapp to work correctly.

Workspaces are, at their essence, the places where all your configurations are stored and can be both local and remote.

The default local workspace

Leapp client is, first and foremost, an open-source project designed to work with secured local data and automate temporary credentials generation. All data needed to generate credentials are stored locally in the Keychain or encrypted configuration files so no one other than the user can access them.

Other than that, we have a plethora of different configurations, such as your preferred terminal or web browser, installed and active plugins, profiles, and a bunch of other things needed for Leapp to work.

It started as a tool for single developers and worked locally, giving us a lot of early feedback until our users began to ask for ways to collaborate and work with their teams, which wasn’t enough.

The zero-trust remote workspace

Working only locally isn't impossible once you start to tread the path of collaborating on access. All Leapp data that wasn’t tied to the single user needed a place to live since a critical Cloud aspect as access requires reliability and robustness.

So we just created a place for everything to be saved online. Easy peasy lemon squeezy, right? But of course not!

From the start, we had the problem of not being happy with doing server-side encryption. It’s ok, but we weren’t satisfied because we wanted something that even the most critical of us would not have a problem using.

Since we’re dev-and-privacy-obsessed, we thought, “What would make our users feel safe storing sensitive data online?”. And the best answer we came up with, together with our users, was to ensure that we can never-ever-ever access your data, even if you ask us to. Everything saved in our server is client-side encrypted; only the user possesses the key to decrypt it.

This enables us to manage your access data while never knowing anything about them, and that’s the reason it’s called zero-knowledge encryption. We don’t know, and can’t know, anything about the encryption key, but you can be at peace storing everything you need to collaborate online.

The Importance of Leapp Collaboration

With persistence sorted out, we are now focusing on the collaborative aspects of Cloud access management. When wielded by an individual, Leapp is a powerful tool, but when groups of people collaborate using Leapp, they can achieve real, transformational benefits. We have always known collaboration is essential for managing, accessing, and securing each Cloud environment.

We’re working closely with Leapp's open-source user community, learning from our users working with Leapp in organizations large and small, and it’s common to find a big gap between the builder’s need for focusing on actual work and the controls needed by security and compliance team managing a cloud environment.

We love IAM, but it’s not quite in the spot to be developer-centric. Powerful and of critical importance, but with many rough edges, and as a central pillar of the Cloud, it’s everywhere. Way too many teams struggle to get their access right with reasonable effort when they need to manage their Cloud Operations at scale. And that’s where we’re looking for the months to come, make Identity and Access management simpler and automated:

• Identity-centric Cloud Access: Seamlessly integrate identities from AWS IAM Identity Center, Okta, Azure AD, Google Workspace, and more.

• IAM Automation: Streamline access management operation tasks and enhance control and visibility over permissions and policies following your organization's workflow and tools.

• Dynamic Roles and Policies: Leverage Leapp's capability to template policies and roles, enabling the effective deployment of different versions based on the environment and context.

• Just-in-time Access: Simplify temporary access management by automating cloud access definition and expiration.

• Automated Least Privilege: Ensure fine-grained permissions and minimize access privileges through Leapp's automation capabilities.

• Zero-trust IAM: Implement a zero-trust approach to identity and access management, enhancing security and reducing risks.

Come to the dark side of IAM; we have cookies (the good ones)

All puns are intended.

This overview has provided some insights into the solution we are developing and the principles behind our choices. The underlying principle on which everything was built is the firm belief that the sole practical method for a Cloud organization to achieve and maintain security is by embracing a developer-led approach.

As we envision the future of this project, we are excited about the possibilities that lie ahead. Our team constantly strives to add new features and improve the user experience based on valuable user feedback. Their input is vital to us, as it helps shape the future of our software.

If you are intrigued by our work and want to join our Closed Beta, please fill out this form or reach out to me on our Slack community. We value the opportunity to collaborate with individuals who share our passion for Identity Access management and security.

Furthermore, we are commencing our Early Adopter Program, specifically designed for organizations that desire a more intimate feedback process and the opportunity to influence the software's development actively. This exclusive program comes with distinct advantages and privileges not accessible to other users, and it customizes our solution to cater to your organization's specific use cases. For this, let’s have a chat or find me on Linkedin!

So, I hope you like what you’re reading, and if you don't want to miss out on this exciting opportunity – reach out to us today! Together we will advance IAM by Leap(p)s and bounds.

It allows developers to automate the process of managing AWS services and resources using scripts, customizing workflows and integrating with other tools.

With the AWS CLI you can also request temporary, limited-privilege credentials for users using AWS Security Token Service or STS, in short.

Knowing how to programmatically use STS via the AWS CLI can be a very useful skill for any DevOps, and this article will provide an overall view of the most common commands.

Prerequisites and Tips

• If you haven't installed the AWS CLI yet, start by looking at Installing the AWS CLI Guide from Amazon.

• Configure the AWS CLI yourself by following this guide, or just let Leapp manage your configuration instead.

• Tip: enable Auto Completion mode for the CLI with $ aws --cli-auto-prompt. This will give you suggestions as you write down your commands. Just remember to exit this mode when you need to run scripts!

AWS CLI filtering flags

AWS CLI commands can accept the following flags: --query, --filter, --output. You can use them or a combination of them to extract, filter and format the JSON output of each command so that it is easily readable and can be passed to other commands.

• --filter is used for server-side filtering and can improve HTTP response times for large data sets.

• --query is used for client-side filtering and can be used to do some more powerful filtering.

• --output is used to format the output, so that it can be transformed into plain text, YAML, etc.

AWS STS CLI: STS assume role

Assuming a role lets you obtain temporary short-lived credentials for that role.

aws sts assume-role --role-arn arn:aws:iam::<account_number>:role/my-role --role-session-name test --region eu-central-1

Flags:

• --role-arn: the ARN of the role to assume

• --role-session-name: optional name for the Session

• --region: the Region in which you want to work in

Output:

{
    "Credentials": {
        "AccessKeyId": "<AccessKeyId>",
        "SecretAccessKey": "<SecretAccessKey>",
        "SessionToken": "<SessionToken>",
        "Expiration": "<ExpirationDate>"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "<IdOfTheAssumedRole>",
        "Arn": "<ARNofTheAssumedRole>"
    }
}

Tips: you can leverage printf to inject credentials directly into environment variables without leaking them in the script. Here’s how to do it:

export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" \\
$(aws sts assume-role \\
--role-arn arn:aws:iam::123456789012:role/MyAssumedRole \\
--role-session-name MySessionName \\
--query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" \\
--output text))

AWS STS CLI: STS assume role with SAML

You can obtain temporary credentials based on a SAML Authentication, using the SAML response.

aws sts assume-role-with-saml --role-arn arn:aws:iam::<account_number>:role/<iam_role> --principal-arn arn:aws:iam::<account_number>:saml-provider/<SAML-provider> --saml-assertion file://samlresponse.txt

Flags:

• --role-arn: the ARN of the role to assume

• --principal-arn: the ARN of the SAML Provider configured in AWS IAM

• --saml-assertion: the SAML assertion contained in a text file

• --duration-seconds: (optional) the duration, in seconds, of the role session. The default value is 3600 seconds. Valid values are from 900 seconds (15 minutes) up to the maximum session duration setting for the role (from 1 to 12 hours).

Outputs:

{
    "Issuer": "<https://integ.example.com/idp/shibboleth></Issuer",
    "AssumedRoleUser": {
        "Arn": "arn:aws:sts::123456789012:assumed-role/TestSaml",
        "AssumedRoleId": "123456EXAMPLE789:TestSaml"
    },
    "Credentials": {
        "AccessKeyId": "<AccessKeyId>",
        "SecretAccessKey": "<SecretAccessKey>",
        "SessionToken": "<SessionToken>",
        "Expiration": "<ExpirationDate>"
    },
    "Audience": "<https://signin.aws.amazon.com/saml>",
    "SubjectType": "transient",
    "PackedPolicySize": "6",
    "NameQualifier": "<NameQualifier>",
    "Subject": "SamlExample"
}

Tips: here’s an example from AWS using awk to store the result of this command in the credential file ./aws/credentials:

awk -F:  '
              BEGIN { RS = "[,{}]" ; print "[PROFILENAME]"}
              /:/{ gsub(/"/, "", $2) }
              /AccessKeyId/{ print "aws_access_key_id = " $2 }
              /SecretAccessKey/{ print "aws_secret_access_key = " $2 }
              /SessionToken/{ print "aws_session_token = " $2 }
' >> ~/.aws/credentials

AWS STS CLI: STS assume role with Web Identity

You can obtain temporary credentials for users who have been authenticated in a mobile or web application with a web identity provider.

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789012:role/FederatedWebIdentityRole --role-session-name ExampleSession --web-identity-token <token>

Flags:

• --role-arn: the ARN of the role to assume

• --role-session-name: the session name

• --web-identity-token: the web identity token obtained from JWT bearer tokens issued by OIDC-compatible identity providers (IdPs)

You must have a valid OAuth 2.0 access token, an OpenID Connect token, and an IAM role that trusts the IdP.

Output:

{
    "SubjectFromWebIdentityToken": "amzn1.account..."
    "Audience": "client.1234567890@apps.example.com",
    "AssumedRoleUser": {
        "Arn": "arn:aws:sts::123456789012:assumed-role/FederatedWebIdentityRole/ExampleSession",
        "AssumedRoleId": "...:ExampleSession"
    }
    "Credentials": {
        "AccessKeyId": "<AccessKeyId>",
        "SecretAccessKey": "<SecretAccessKey>",
        "SessionToken": "<SessionToken>",
        "Expiration": "<ExpirationDate>"
    },
    "Provider": "www.amazon.com"
}

AWS STS CLI: STS get session token

You can obtain temporary credentials for an AWS account or IAM user. The credentials consist of an access key ID, a secret access key, and a security token. Can be used with MFA-enabled IAM users.

aws sts get-session-token

Flags:

• --duration-seconds: (optional) the duration, in seconds, of the role session. The default value is 3600 seconds.

• --serial-number: (optional) the ID of the MFA device, either a serial number for a hardware device or an ARN for a virtual device

• --token-code: (optional) the value provided by the MFA device

Output:

{
   "Credentials": {
        "AccessKeyId": "<AccessKeyId>",
        "SecretAccessKey": "<SecretAccessKey>",
        "SessionToken": "<SessionToken>",
        "Expiration": "<ExpirationDate>"
   }
}

AWS STS CLI: STS get federation token

You can obtain temporary security credentials for a user. Can be used to get temporary security credentials on behalf of distributed applications inside a corporate network.

aws sts get-federation-token --name Bob

Flags:

• --name: the name of the federated user. The name is used as an identifier for the temporary security credentials (such as Bob)

Output:

{
  "Credentials": {
        "AccessKeyId": "<AccessKeyId>",
        "SecretAccessKey": "<SecretAccessKey>",
        "SessionToken": "<SessionToken>",
        "Expiration": "<ExpirationDate>"
  },
  "FederatedUser": {
    "Arn": "arn:aws:sts::123456789012:federated-user/Bob",
    "FederatedUserId": "123456789012:Bob"
  },
  "PackedPolicySize": 6
}

Tips:

If you want to compare all AWS STS methods of generating temporary credentials, this table from the AWS documentation can be very useful.

AWS STS CLI: STS get caller identity

You can use this command to see who the credentials set belongs to.

aws sts get-caller-identity

Flags:

• --profile: (optional) the named profile, specified in the .aws/credentials file, for the credentials set you want.

Output:

{
    "UserId": "<UserId>",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/..."
}

If this command returns "Unable to locate credentials", make sure you have a [default] named profile in the .aws/credentials file! Otherwise, use the --profile flag.

Tips:

You can use this command to quickly find your account ID.

aws sts get-caller-identity --query Account --output text

Conclusions

This article continued exploring how the AWS CLI can be used to automate operations on AWS services, in particular with STS.

We explored all the different commands that we have at our disposal and how to generate temporary credentials for accessing our AWS resources.

We also introduced and explained some useful flags to give some extra spice to our output format and filter out all the unwanted information.

Thank you for sticking with us until the end of this short cheat sheet, hopefully, you learned something new!

As always, if you have any questions, need clarification, or just want to share your opinion, feel free to join our Top of the Ops community.

See you in the Cloud!

Session Manager lets you connect to different types of EC2 instances using a browser or the AWS CLI, like a cross-platform SSH connection, but managed by AWS without needing a public IP address.

When you use Linux instances, AWS SSM Session Manager helps to ssh into private EC2 instances, but what about Windows instances?

If you start Session Manager, you’ll get only a PowerShell prompt, and, as much as we love command lines, sometimes we are more familiar with a GUI.

Why a bastion host or a remote desktop gateway is not a good idea

When you use a private instance, you want to restrict its connectivity from the internet as much as possible.

If you use a bastion host for port forwarding or a remote desktop gateway server, issues can arise in the future because you will need to maintain a service exposed on the Internet.

AWS Fleet Manager RDP: the missing feature

If you want to use RDP without giving additional connectivity to the internet, you can use AWS Fleet Manager, so you will have a web client to use the GUI. Sooner or later, you will discover a missing feature: you cannot copy files from and to your instance. Luckily for you, we have already investigated a solution!

AWS System Manager Port Forwarding to the rescue

Lucky for us, System Manager has a very useful Managed Document we can use to achieve our goal: AWS-StartPortForwardingSession

This document allows us to create a tunnel from our PC to an EC2 instance, even if it is in a private subnet. The only requirement is to have the SSM Agent installed and to have connectivity to the SSM service API; you can also deploy a private endpoint if there is no internet connectivity.

From our local environment, we can launch:

aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3389"], "localPortNumber":["56789"]}'

Then we can connect to [localhost:56789](http://localhost:56789)`` using our favorite RDP client, and we can use all the features of the RDP protocol, such as clipboard sharing, copying files, drive mapping, remote audio, and so on. Systems Manager will do the magic of forwarding everything inside a secure channel.

We also have another trick up our sleeves: another SSM Document (AWS-StartPortForwardingSessionToRemoteHost) can allow us to do remote port forwarding to access other private services, such as an RDS database.

aws ssm start-session \
    --target instance-id \
    --document-name AWS-StartPortForwardingSessionToRemoteHost \
    --parameters '{"host":["mydb.example.us-east-2.rds.amazonaws.com"],"portNumber":["3306"], "localPortNumber":["3306"]}'

With this command, we are using the private instance to forward traffic to an RDS Instance (ensure that traffic is allowed by the security group; otherwise, the connection will fail).

Leapp to the rescue!

I love using the command line, but I’m not tidy enough to make scripts and aliases to organize all my connections (and if I make an alias, I often forget my alias name).

Luckily, Christian made a plugin that has become my all-time favorite: LEAPP-SSM-TUNNELS-PLUGIN

This plugin uses only AWS-StartPortForwardingSessionToRemoteHost Document, but we can use “localhost” as the remote host, so it will behave like AWS-StartPortForwardingSession

You can download it from Leapp Plugins and once activated, you need to configure it using a JSON file (ssm-conf.json in the Leapp configuration directory). You can find the documentation in the official repository:

Here’s an example of forwarding port 3389 to an instance named “test-instance”

[
  {
    "sessionName": "leapp-account1-demo-session",
    "configs": [
      {
        "targetTagKey": "Name",
        "targetTagValue": "test-instance",
        "host": "localhost",
        "portNumber": "3389",
        "localPortNumber": "5678"
      }
    ] 
  }
]

You can add as many entries for Leapp sessions and configs as you want. Remember to change the localPortNumber parameter to avoid conflicts.

Here’s an example with three instances in two different AWS accounts:

[
  {
    "sessionName": "leapp-account1-demo-session",
    "configs": [
      {
        "targetTagKey": "Name",
        "targetTagValue": "test-instance",
        "host": "localhost",
        "portNumber": "3389",
        "localPortNumber": "5678"
      },
      {
        "targetTagKey": "Name",
        "targetTagValue": "anothertest-instance",
        "host": "localhost",
        "portNumber": "3389",
        "localPortNumber": "8901"
      }
    ] 
  },
 {
    "sessionName": "leapp-account2-demo-session",
    "configs": [
      {
        "targetTagKey": "Name",
        "targetTagValue": "test-instance-another-account",
        "host": "localhost",
        "portNumber": "3389",
        "localPortNumber": "1234"
      }
]

Once you configure the plugin, you can use the context menu on an account to start all the remote port forwarding sessions. Leapp will take care of the authentication and SSM Document interaction.

That’s it! No command lines to search through the shell history and no aliases to remember.

A new service: EC2 Instance Connect Endpoint

While writing this article, a new announcement was made at the re:Inforce event in Los Angeles: you can deploy an endpoint in your VPC to avoid bastion hosts entirely.

This is a good addition, and it works fine, but there are some things that you have to take into consideration:

• You have to configure your security groups to allow connections

• It only works for RDP or SSH

• You have to pay for the endpoint

There’s also an additional problem: this service is not organization-wide and cross-account at the time of writing. I would have preferred a more comprehensive solution with large organizations in mind.

On the other hand, it’s a fully managed service, and it’s brand new, so expect new features to be added!

Conclusions

Connecting to private EC2 instances has always been time-consuming because you must maintain additional infrastructure components.

Now with SSM, Leapp, or EC2 Instance Connect, there are easier ways; which solution to use is up to your taste.

Do you use other methods to manage private instances? Let us know in the comments.

A special thank you to Christian Calabrese for the Leapp plugin: I owe you a beer! :)

It is an open-source tool, and knowing how to use it to interact with AWS Services is crucial, especially for Developers.

It allows to centralize control of all existing services from a single tool, and moreover, to make automated scripts.

AWS Identity & Access Management, IAM in short, provides fine-grained access control across AWS services.

This article will show how to use the AWS CLI to perform all the most common IAM operations.

Prerequisites and Tips

• If you haven't installed the AWS CLI yet, start by looking at Installing the AWS CLI Guide from Amazon.
• Download jq, a lightweight and flexible JSON processor for your terminal. Highly recommend for automated script with the AWS CLI. Look at the site for more information.
• Get the AWS CLI version: $ aws --version.

• Get the AWS CLI installation path: $ which aws.

• Configure the AWS CLI for the first time: follow our previous article.
• $ aws --cli-auto-prompt: enable Auto Completion mode for the CLI, giving you suggestions as you write down your commands. Just remember to exit this mode when you need to run scripts!

AWS CLI: Versions

• Version 2.x — Used primarily for production environments.
• Version 1.x — Now available only for backward compatibility.

AWS CLI: command anatomy

Users can create commands in single or multiple lines. The \ character splits a command into multiple lines for better readability.

In general, a command is structured in this way:

You have the CLI invocation, and then you apply a command to a specific service. You can also add many different optional parameters.

AWS IAM CLI: table of content

There are many different commands that you can exploit using the AWS CLI, but this article will focus only on those related to IAM and STS (AWS Security Token Service).

Because commands can have many optional parameters, we recommend opening this link in your browser for further reference information.

Note: you can use the TOC feature to jump to your desired command.

AWS IAM CLI: create user

Create a new IAM user.

aws iam create-user --user-name AlessandroArticle

• iam: Service
• create-user: Command
• --user-name: Name of the user

Output:

{
    "User": {
        "Path": "/",
        "UserName": "AlessandroArticle",
        "UserId": "<user_id>",
        "Arn": "arn:aws:iam::<account_number>:user/AlessandroArticle",
        "CreateDate": "<creation_date>"
    }
}

AWS IAM CLI: list users

Lists all users in the credentials’ set account.

aws iam list-users

• iam: Service
• list-users: Command

Output:

{
    "Users": [
        {
            "Path": "/",
                "UserName": "AlessandroArticle",
                "UserId": "<user_id>",
                "Arn": "arn:aws:iam::<account_number>:user/AlessandroArticle",
                "CreateDate": "<creation_date>"
        }
        ]
}

AWS IAM CLI: update user

Updates an IAM user. We can update the name of a user using the update-user command.

aws iam update-user --user-name AlessandroArticle --new-user-name AlessandroArticleNew

• iam: Service
• update-user: Command
• —-user-name: The old name
• —-new-user-name: The new name

AWS IAM CLI: delete user

Deletes the specified IAM user.

aws iam delete-user —user-name AlessandroArticle

• iam: Service
• update-user: Command
• —-user-name: The name of the user to remove

Note: you must delete the items attached to the user before attempting to delete a user, otherwise the command will fail (as per AWS documentation):

• Password ( DeleteLoginProfile )
• Access keys ( DeleteAccessKey )
• Signing certificate ( DeleteSigningCertificate )
• SSH public key ( DeleteSSHPublicKey )
• Git credentials ( DeleteServiceSpecificCredential )
• Multi-factor authentication (MFA) device ( DeactivateMFADevice , DeleteVirtualMFADevice )
• Inline policies ( DeleteUserPolicy )
• Attached managed policies ( DetachUserPolicy )
• Group memberships ( RemoveUserFromGroup )

Pro tips:

List userId and UserName

aws iam list-users | jq -r ‘.Users[ ]|.UserId+” “+.UserName’

Get single user

aws iam get-user --user-name (username)

Add user

aws iam create-user --user-name (username)

Delete user

aws iam delete-user --user-name (username)

List access keys for user

aws iam list-access-keys --user-name (username) | jq -r .AccessKeyMetadata[ ].AccessKeyId

Delete access key for user

aws iam delete-access-key --user-name (username) --access-key-id (accessKeyID)

Activate/deactivate access key for user

aws iam update-access-key --status Active --user-name (username) --access-key-id (access key)

aws iam update-access-key --status Inactive --user-name (username) --access-key-id (access key)

Generate new access key for user

aws iam create-access-key --user-name (username) | jq -r ‘.AccessKey | .AccessKeyId+” “+.SecretAccessKey’

AWS IAM CLI: create IAM policy

Creates a new IAM policy.

aws iam create-policy --policy-name example-policy --policy-document file://example-policy.json

• iam: Service
• create-policy: Command
• --policy-name: Name of the IAM policy
• --policy-document: Policy document in JSON format (useful because the policies are structured files)

An example policy document:

{
    "Version": "2012-10-17",
    "Statement": [
        {
              "Effect": "Allow",
              "Action": [
                "s3:GetBucketLocation",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads"
              ],
              "Resource": [
                "arn:aws:s3:::<my_bucket>"
              ]
            }
    ]
}

Output:

{
   "Policy": {
      "PolicyName":"example-policy",
      "PolicyId":"<policy_id>",
      "Arn":"arn:aws:iam::<account_number>:policy/example-policy",
      "Path":"/",
      "DefaultVersionId":"v1",
      "AttachmentCount":0,
      "PermissionsBoundaryUsageCount":0,
      "IsAttachable":true,
      "CreateDate":"<creation_date>",
      "UpdateDate":"<update_date>"
   }
}

AWS IAM CLI: list IAM policies

Lists IAM policies in the account.

aws iam list-policies --scopes All

• iam: Service
• list-policies: Command
• --scopes: Policies scope. Possible values: All, AWS, Local. AWS is for managed policies, while Local for custom policies.

Output

{
    "Policies": [
        {
           "Policy": {
              "PolicyName":"example-policy",
              "PolicyId":"<policy_id>",
              "Arn":"arn:aws:iam::<account_number>:policy/example-policy",
              "Path":"/",
              "DefaultVersionId":"v1",
              "AttachmentCount":0,
              "PermissionsBoundaryUsageCount":0,
              "IsAttachable":true,
              "CreateDate":"<creation_date>",
              "UpdateDate":"<update_date>"
           }
        }
    ]
}

AWS IAM CLI: update IAM policy

Edit an IAM policy and set it as default.

aws iam create-policy-version \
 --policy-arn arn:aws:iam::123456789012:policy/my-policy \
 --policy-document file://NewPolicyVersion.json --set-as-default

• iam: Service
• create-policy-version: Command
• --policy-arn: ARN of the policy
• --policy-document: Updated policy file

AWS IAM CLI: delete IAM policy

Delete a policy given the ARN.

aws iam delete-policy --policy-arn arn**:**aws**:**iam**::**123456789012**:**policy/my-policy

• iam: Service
• delete-policy: Command
• --policy-arn: ARN of the policy

AWS IAM CLI: create IAM role

Creates a new IAM role. The arguments for this command are:

aws iam create-role --role-name example-role --assume-role-policy-document file://assume-policy.json

• iam: Service
• create-role: Command
• --role-name: Name of the IAM role
• --assume-role-policy-document: Trust relationship policy document that grants an entity permission to assume the role

In this example, we will create an IAM role that grants AWS Glue permission to assume the role (as principal).

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
        "Service": "glue.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

Output:

{
    "Role": {
        "Path": "/",
        "RoleName": "example-role",
        "RoleId": "<role_id>",
        "Arn": "arn:aws:iam::<account_number>:role/example-role",
        "CreateDate": "<creation_date>",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "glue.amazonaws.com"
                    },
                    "Action": "sts:AssumeRole"
                }
            ]
        }
    }
}

AWS IAM CLI: delete a Role

Deletes an IAM Role.

aws iam delete-role --role-name Test-Role

• iam: Service
• delete-role: Command
• --role-name: Name of the IAM Role to remove

AWS IAM CLI: attach policy to a User

To allow a User to do some actions, apply a policy to it.

aws iam attach-user-policy --user-name AlessandroArticle --policy-arn arn:aws:iam::<policy_id>:policy/my-policy

• iam: Service
• attach-user-policy: Command
• --user-name: Name of the IAM user
• --policy-arn: ARN of the IAM policy to attach

In this example, we will attach the IAM policy we created earlier to an example IAM.

AWS IAM CLI: attach policy to an IAM role

We can also attach a policy to a IAM role.

aws iam attach-role-policy --role-name example-role --policy-arn arn:aws:iam::<policy_id>:policy/my-policy

• iam: Service
• attach-role-policy: Command
• --role-name: Name of the IAM role
• --policy-arn: ARN of the IAM policy you want to attach

AWS IAM CLI: list all policies attached to a user

We can list all policies attached to an IAM User.

aws iam list-attached-user-policies --user-name AlessandroArticle

• iam: Service
• list-attached-user-policies: Command
• --user-name: The User to whom the policies are attached to

Output

{
    "AttachedPolicies": [
        {
            "PolicyName": "my-policy",
            "PolicyArn": "arn:aws:iam::<account_number>:policy/learnaws-dynamo-policy"
        }
    ]
}

AWS IAM CLI: list all policies attached to a role

List all policies attached to an IAM Role.

aws iam list-attached-role-policies --role-name example-role

• iam: Service
• list-attached-role-policies: Command
• --role-name: The Role to whom the policies are attached to

Output

{
    "AttachedPolicies": [
        {
            "PolicyName": "my-policy",
            "PolicyArn": "arn:aws:iam::<account_number>:policy/example-policy"
        }
    ]
}

Output:

{
    "UserId": "AROAJQ3ISEWFFR6GXAW:<user_name>",
    "Account": "637004329899",
    "Arn": "arn:aws:sts::637004329899:assumed-role/<role-name>/<user_name>"
}

AWS IAM CLI: jq snippets

Finally, thanks to the excellent tutorial from BlueMatador, here we present some fast snippets that integrate the jq tool to extrapolate useful info for different use-cases. Kudos to them 🙂.

List groups

aws iam list-groups | jq -r .Groups[ ].GroupName

Add/Delete groups

aws iam create-group --group-name (groupName)

List policies and ARNs

aws iam list-policies | jq -r ‘.Policies[ ]|.PolicyName+” “+.Arn’

aws iam list-policies --scope AWS | jq -r ‘.Policies[ ]|.PolicyName+” “+.Arn’

aws iam list-policies --scope Local | jq -r ‘.Policies[ ]|.PolicyName+” “+.Arn’

List user/group/roles for a policy

aws iam list-entities-for-policy --policy-arn arn:aws:iam:2308345:policy/example-ReadOnly

List policies for a group

aws iam list-attached-group-policies --group-name (groupname)

Add policy to a group

aws iam attach-group-policy --group-name (groupname) --policy-arn arn:aws:iam::aws:policy/exampleReadOnlyAccess

Add user to a group

aws iam add-user-to-group --group-name (groupname) --user-name (username)

Remove user from a group

aws iam remove-user-from-group --group-name (groupname) --user-name (username)

List users in a group

aws iam get-group --group-name (groupname)

List groups for a user

aws iam list-groups-for-user --user-name (username)

Attach/detach policy to a group

aws iam attach-group-policy --group-name (groupname) --policy-arn arn:aws:iam::aws:policy/DynamoDBFullAccess

aws iam detach-group-policy --group-name (groupname) --policy-arn arn:aws:iam::aws:policy/DynamoDBFullAccess

Conclusions

This article shows that AWS CLI is a powerful tool for automatic operations on AWS services.

In particular, we have used IAM and STS services to explore all the different commands that we can leverage for Access Management and Identity governance.

We have demonstrated that AWS CLI commands can be chained with other terminal tools to push even further your automation scripts.

Finally, we have seen how jq can be a perfect companion for the CLI to obtain properties out of JSON-formatted files or command results.

If this article interested you, next week we will continue with a new cheatsheet correlated to STS and how it is tied closely to our open-source tool Leapp. Don’t miss it out!

Thank you everyone, for coming this far. We hope that you enjoyed this little “cheatsheet”.

As always, if you have questions, clarifications, or just want to share your opinions, feel free to join our Top of the Ops community.

Until next time, stay safe 🙂!

As organizations evolve, they may look at multi-cloud as a solution to consume cloud services in different cloud providers' technologies (such as AI/ML, data analytics, and more), to have the benefit of using different pricing models, or to decrease the risk of vendor lock-in.

Before we begin the discussion about IAM, we need to understand the following fundamental concepts:

• Identity – An account represents a persona (human) or service (non-interactive account)

• Authentication – The act where an identity proves himself against a system (such as providing username and password, certificate, API key, and more)

• Authorization – The act of validating granting an identity’s privileges to take actions on a system (such as view configuration, read database content, upload a file to object storage, and more)

• Access Management – The entire lifecycle of IAM – from account provisioning, granting access, and validating privileges until account or privilege revocation

Identity and Access Management Terminology

Authorization in the Cloud

Although all cloud providers have the same concept of identities, when we deep dive into the concept of authorization or access management to resources/services, we need to understand the differences between cloud providers.

Authorization in AWS

AWS has two concepts for managing permissions to resources:

• IAM Role – Permissions assigned to an identity temporarily.

• IAM Policy – A document defines a set of permissions assigned to an IAM role.

Permissions in AWS can be assigned to:

• Identity – A policy attached to a user, group, or role.

• Resource – A policy attached to a resource (such as Amazon S3 bucket).

Authorization in Azure

Permissions in Azure AD are controlled by roles.

A role defines the permissions an identity has over an Azure resource.

Within Azure AD, you control permissions using RBAC (Role-based access control).

Azure AD supports the following types of roles:

• Built-in roles – A pre-defined role according to job function (as you can read on the link).

• Custom roles – A role that we create ourselves to match the principle of least privilege.

Authorization in Google Cloud

Permissions in Google Cloud IAM are controlled by IAM roles.

Google Cloud IAM supports the following types of IAM roles:

• Basic roles – The most permissive type of roles (Owner, Editor, and Viewer).

• Predefined roles – Roles managed by Google, which provides granular access to specific services (as you can read on the link).

• Custom roles – User-specific roles, which provide the most granular access to resources.

Authorization – Default behavior

As we can see below each cloud provider takes a different approach to default permissions:

• AWS – By default, new IAM users have no permission to access any resource in AWS.
  To allow access to resources or take actions, manually assign the user an IAM role.

• Azure – By default, all Azure AD users are granted a set of default permissions (such as listing all users, reading all properties of users and groups, registering new applications, and more).

• Google Cloud – By default, a new service account is granted the Editor role on the project level.

Identity Federation

When we are talking about identity federation, there are two concepts:

• Service Provider (SP) – Provide access to resources

• Identity Provider (IdP) – Authenticate the identities

Identities (user accounts, service accounts, groups, etc.) are managed by an Identity Provider (IdP).

An IdP can exist in the local data center (such as Microsoft Active Directory) or the public cloud (such as AWS IAM, Azure AD, Google Cloud IAM, etc.)

Federation is the act of creating trust between separate IdP’s.

Federation allows us to keep identity in one repository (i.e., Identity Provider).

Once we set up an identity federation, we can grant an identity privilege to consume resources in a remote repository.

Example: a worker with an account in Microsoft Active Directory, reading a file from object storage in Azure, once a federation trust was established between Microsoft Active Directory and Azure Active Directory.

When federating between the on-premise and cloud environments, we need to recall the use of different protocols.

On-premise environments are using legacy authentication protocols such as Kerberos or LDAP.

In the public cloud, the common authentication protocols are SAML 2.0, Open ID Connect (OIDC), and OAuth 2.0

Each cloud provider has a list of supported external third-party identity providers to federate with, as you can read in the list below:

• Integrating third-party SAML solution providers with AWS

• Azure AD Identity Provider Compatibility Docs

• Google Cloud IAM - Configure workforce identity federation

Single Sign-On

The concept behind SSO is to allow identities (usually end-users) access to resources in the cloud while having to sign (to an identity provider) once.

Over the past couple of years, the concept of SSO was extended and now it is possible to allow a single identity (who authenticated to a specific identity provider), access to resources over federated login to an external (mostly SAML) identity provider.

Each cloud provider has its own SSO service, supporting federation with external identity providers:

• AWS IAM Identity Center

• Azure Active Directory single sign-on

• Google Cloud Workload identity federation

Steps for creating a federation between cloud providers

The process below explains (at a high level) the steps require to set up identity federation between different cloud providers:

1. Choose an IdP (where identities will be created and authenticated to).

2. Create a SAML identity provider.

3. Configure roles for your third-party identity provider.

4. Assign roles to the target users.

5. Create trust between SP and IdP.

6. Test the ability to authenticate and identify (user) to a resource in a remote/external cloud provider.

Additional References:

• AWS IAM Identity Center and Azure AD as IdP

• How to set up IAM federation using Google Workspace

• Azure AD SSO integration with AWS IAM Identity Center

• Azure AD SSO integration with Google Cloud / G Suite Connector by Microsoft

• Federating Google Cloud with Azure Active Directory

• Configure Google workload identity federation with AWS or Azure

Summary

In this blog post, we deeply explored identity and access management in the cloud, comparing different aspects of IAM in AWS, Azure, and GCP.

After we have reviewed how authentication and authorization work for each of the three cloud providers, we have explained how federation and SSO work in a multi-cloud environment.

Important to keep in mind:

When we are building systems in the cloud, whether they are publicly exposed or even internal, we need to follow some basic rules:

• All-access to resources/systems/applications must be authenticated

• Permissions must follow the principle of least privileged and business requirements

• All access must be audited (for future analysis, investigation purposes, etc.)

About the Author

Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7, and the author of the book Cloud Security Handbook, with over 20 years in the IT industry.
Eyal is an AWS Community Builder since 2020.
You can connect with him on Twitter and LinkedIn.

Users, Roles and Policies are terms that we learn pretty early in our career, however, there is one concept that has a lot of meaning behind it and, in my opinion, deserves a little more explanation: IAM Principal!

IAM Principal: definition

Let’s start by giving a standard definition: a principal is a human user or workload that can make a request for an action or operation on an AWS resource.

Moreover, a principal is anything, AWS related, that can send a request to AWS, via the Management Console, the AWS API, or the AWS CLI.

IAM Principal: actors

In AWS What or Who are the “actors” that can be referred as Principals?

• Root User

• IAM Users

• IAM Roles/Temporary Security Tokens

The main differences among them are Who can impersonate them, and What credentials they are granted.

Users are impersonated by human users while Roles by services, or workloads in general.

Also, while the first actors are granted long-lived credentials, Roles use temporary credentials.

Root user

The Root user is the owner of the AWS main Account, and it should be protected by MFA and a strong password right after registering. We should avoid using the Root user as a Principal, for security reasons, and instead use IAM Users and Roles.

He accesses AWS with email and password: that is why we must avoid using it for operation work!

IAM Users

an IAM user is a persistent entity that is given a set of credentials to manage services on AWS. The IAM User can be associated with both long or short-lived credentials (tough short-lived ones are much preferred).

An IAM User can be authorized to perform actions directly via an AWS Policy attached to it, or via a Group Policy.

An IAM User is created through:

• AWS Management Console

• CLI

• SDKs

IAM Role

an IAM Role is a Principal associated directly with AWS Resources or assumed by an IAM User, the AWS CLI, or one of the AWS SDKs available. It has permissions granted via temporary credentials. It has one or more Policies attached to it.

Some use cases related to IAM Roles involve:

• Amazon EC2 Roles: grant permissions to applications running on an Amazon EC2 instance.

• Cross-Account Access: grant permissions to users from other AWS accounts, whether in control of those accounts or not.

Temporary Security Tokens:

Temporary Security Tokens are obtained from the AWS Security Token Service (STS).

They always have an expiration date and time, and have a lifespan between 15 minutes and up to 36 hours.

These tokens are usually obtained through a Federation Process, which involves granting permissions to users authenticated by a trusted external system.

Here is a summary from AWS showing some types of Roles/Temporary Security Tokens and from what they are obtained:

A special mention goes to AWS SSO Users that are configured via IAM Identity Center permission sets to access different accounts with different roles. When a user lands on an account a role is given transparently to access services and resources according to the policies set up by the administrator.

IAM Roles, AWS SSO, and Temporary Security Tokens are meant for advanced AWS IAM usage and have always a limited set duration of time.

Because these Principals are extremely important and versatile, I strongly advise reading more on the argument, starting from this article and also this one, concluding with this one from AWS Hero Matt Lewis.

IAM Principal: authentication, requests, and authorization

When working with Principals we must understand the two actions that must be taken to finally obtain a set of valid Credentials.

First Authentication of the subject against AWS or a valid Identity Provider, and then Authorization to be able to perform actions and access specific resources.

IAM Principal: Authentication

A Principal must always authenticate to send AWS requests.

Only Amazon S3, SQS, SNS, and AWS STS allow limited (and specific) requests from anonymous users, but they're the exception.

To log in as a Root User on the console, use your email and password.

As a Federated User, you can access AWS resources through IAM roles granted by your identity provider's authentication.

Enter your Access Key ID and Secret Access Key to authenticate as an IAM user.

To authenticate workloads, use temporary or long-term credentials (always preferring the first).

DevOps’ best practices recommend using MFA and temporary credentials to keep your account secure.

IAM Principal: Request

When a principal tries to do something with AWS using the AWS Management Console, an SDK, or the CLI, it sends a request to AWS with the following information:

• Actions or operations: the actions to perform.

• Resources: the AWS services or objects to manipulate.

• Principal: and now we know what they can be 😀!

• Environment data: various metadata, like IP address, User agent, etc.

• Resource data: metadata depending on the specific AWS resource.

AWS puts all of these in a request context, which is used to evaluate and authorize the request.

IAM Principal: Authorization

After Authentication, you must also be authorized to complete your request.

During the authorization process, AWS uses the request context to check for policies that conform to the request.

It then parses the policies to determine whether to allow or deny the request.

Most policies are stored in AWS as JSON documents and specify the permissions for principal entities. There are several types of policies that can affect the outcome of the request.

If a single permissions policy includes a denied action, AWS denies the entire request and stops evaluating.

Because requests are denied by default, they can complete only if every part of the request is allowed by the permissions policies.

The general rules to understand how the authorization works are the following:

• By default, all requests are denied.

• An explicit allow (identity-based or resource-based) overrides the default deny.

• Organizations' SCPs, IAM permissions boundaries, or session policies override the allow. But if there is more than one of these policies, they all need to allow the request.

• An explicit denial in any policy overrides any allows.

To learn more about how this process is evaluated, see Policy evaluation logic.

IAM Principal: Credentials

As we have seen there are two types of credentials granted to a Principal: long-lived and temporary short-lived.

Long-lived credentials last until an administrator explicitly removes them from a Principals and usually, are applied to Root Users and IAM Users/Groups.

Short-lived credentials are temporary, and have an explicit expiration date and time.

They are generated through AWS STS Service and are associated with IAM Roles, Assumed Roles, or even Federated Identities (AWS SSO, Web, SAML, OIDC, OAuth, Cognito, Azure AD, etc.)

IAM Principal: Best Practices

As short-lived credentials can also be applied to a Group or a User thanks to the Assume Role action, I strongly recommend adhering to DevOps best practices and always using short-lived credentials whenever possible.

It is preferable to use temporary credentials because they reduce the potential damage done by an attacker stealing them (they are limited in time).

It is also savvy to narrow down policies associated with users and roles to the bare minimum set of resources that you need for your work. Always take advantage of the Deny First rules!

With the Introduction of IAM Identity Center is always preferable for administrators to use it for creating new Users as they will also benefit from a landing panel to choose the account and role from.

Sum Up

In this short article, we learned about AWS IAM Principals, how they are categorized, and what they stand for.

We have learned that IAM Principals have to deal with both an Authentication and an Authorization process to be able to operate successfully on AWS.

We have seen what a request, made to AWS by a Principal, contains.

We have seen what a Root account and an IAM User are, how they differ from IAM Roles, and moreover from Temporary Security Tokens.

We have analyzed the differences between Long and Short-lived Credentials, and why the latter are preferable and more secure.

We have proposed some basic best practices to follow to better use your AWS Principals.

So, thank you all for reaching the end of the article!

As always, if you have suggestions or questions, feel free to come and have a chat with us on our Slack community.

Until next time, see ya and stay safe! 🙂

It’s always a best practice to check if the API request target is the one that you expect, especially if the operations that are about to be performed may have major repercussions on your AWS accounts.

Who am I in the context of AWS?

When it comes generate temporary credentials and get information about them, AWS Security Token Service (AWS STS) comes to the rescue.

“Who am I in the context of AWS” is exactly the question the AWS STS GetCallerIdentity API provides an answer to. The answer tells you what is the account affected by the next API call if credentials are not going to change in the meanwhile.

Yes, I mentioned AWS STS. Indeed, this is the service that I should call upon to get that information. To interface with the GetCallerIdentity API, two requirements must be fulfilled:

• network connectivity;

• a valid set of AWS Credentials, placed in one of the locations the client that you’re using expects them to be (environment variables, shared configuration files, etcetera). As you can see on this documentation page, authentication information is added to the request via the Authorization Header.

The reference client used in this article is the AWS CLI (Command Line Interface). The AWS CLI command that you should issue to get this information is the following:

aws sts get-caller-identity

aws sts get-caller-identity response structure

Regardless of the IAM identity used to authenticate the request, the API response always contains three fields:

• UserId - the unique identifier of the calling entity;

• Account - the AWS Account ID number of the account that owns or contains the calling entity;

• Arn - the Amazon Resource Name associated with the calling identity.

While the Account field is always a 12-digits number, Arn and UserId depend on the principal that initiated the request.

In this blog post, we’ll focus on two categories of principals: User and AssumedRole.

The User category simply corresponds to the IAM User principal.

The AssumedRole category covers more principals, but we’ll focus on SAML federated user (assumed via AssumeRoleWithSAML API), assumed role (assumed via AssumeRole API), and role assigned to an Amazon EC2 instance.

For a complete overview of principals, please refer to the documentation.

Now, let’s deepen the UserId and Arn fields for each of the previously cited principals.

IAM User

{
    "UserId": "AIDACKCEVSQ6C2EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/JohnDoe"
}

The UserId corresponds to the unique ID of the IAM User.

The Arn field adheres to the following template: arn:aws:iam::<account-id>:user/<user-name-with-path>.

SAML federated user

{
    "UserId": "AROACKCEVSQ6C2EXAMPLE:johndoe@example.com",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/john.doe/johndoe@example.com"
}

The UserId consists of the unique ID of the role (AROACKCEVSQ6C2EXAMPLE) and the caller specified role name (johndoe@example.com).

The caller specified role name corresponds to the RoleSessionName attribute that is part of the SAML assertion.

The SAML assertion is an authentication response forwarded by the external IdP to the https://region-code.signin.aws.amazon.com/saml endpoint. The SAML assertion contains a set of claims; the RoleSessionName is one of them.

Typically, the value of the RoleSessionName attribute is a user ID or an email address. As explained in this blog post by my fellow colleague Nicolò Marchesi, when it comes to federating a G Suite IdP to an AWS account, the RoleSessionName SAML attribute is mapped to the G Suite user’s Primary Email.

The Arn field adheres to the following template: arn:aws:iam::<account-id>:assumed-role/<role-name>/<role-session-name>. The Principal Type is not a user - as for the IAM User - but an assumed-role. Indeed, the SAML-based federation allows a user - managed by the external IdP - to assume an AWS Role via the STS assumeRoleWithSAML API.

Assumed role

This principal corresponds to an IAM Role assumed via the AssumeRole API. Using this API, an IAM Role can be assumed by either an IAM User, an AWS IAM Identity Center user, or another IAM Role (the last configuration is called role chaining).

All these configurations provide the same GetCallerIdentity API response structure.

{
    "UserId": "AROACKCEVSQ6C2EXAMPLE:FakeRoleSessionName",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/FakeRoleName/FakeRoleSessionName"
}

As for the SAML federated user scenario, the Arn field adheres to the following template: arn:aws:iam::<account-id>:assumed-role/<role-name>/<role-session-name>.

The UserId field is composed of the unique id of the role and the caller specified role name that is specified by the RoleSessionName parameter passed to the AssumeRole request.

Role assigned to an Amazon EC2 instance

When you launch an Amazon EC2 instance, you specify an IAM role to associate with the instance. Applications that run on the instance can then use the role-supplied temporary credentials to sign API requests. To be precise, the IAM Role is encapsulated in an Instance Profile which can provide the role’s temporary credentials to an application that runs on the instance.

When you call the AWS STS GetCallerIdentity API, the request is signed using the temporary credentials supplied via the Instance Profile. The following is an example response.

{
    "Account": "123456789012",
    "UserId": "AROACKCEVSQ6C2EXAMPLE:i-1234567890abcdef0",
    "Arn": "arn:aws:sts::123456789012:assumed-role/iam-role-name/i-1234567890abcdef0"
}

The UserId field is composed of the unique id of the role (AROACKCEVSQ6C2EXAMPLE) and the unique identifier of the EC2 instance (i-1234567890abcdef0).

The Arn field adheres to the following template: arn:aws:iam::<account-id>:assumed-role/<role-name>/<role-session-name>. The <role-name> corresponds to iam-role-name while the <role-session-name> corresponds to the unique identifier of the EC2 instance.

That’s all Folks!

In this blog post, I’ve provided you with a description of the API that you can consume to answer the question “Who am I in the context of AWS?”. The answer to that question can vary, depending on the Principal associated with the IAM Credentials used to sign the GetCallerIdentity API.

Reach out to me, if you want to enrich the list of most common scenarios where you can find yourself in.

Stay tuned for new publications!

In this article, we will explore the fundamentals of AWS IAM, including its key concepts, best practices, and how to work with IAM to manage an organization.

Whether you are new to AWS or an experienced developer, this article will provide you with the knowledge you need to get started with AWS IAM.

Introduction to IAM

IAM is one of the services that is straightforward to start, but hard to master, as the power lies in the wide range of features.

What is AWS IAM?

With AWS Identity and Access Management (IAM), you can securely manage access to AWS services and resources. You won't have to juggle multiple credentials anymore - instead, you can use roles and policies to grant precise permissions. These permissions can be assigned not only to users but also to resources, for ultimate control.

Why is IAM Important?

AWS IAM plays a crucial role in ensuring the security of AWS, as it guarantees that only authorized individuals can access your resources. Acquiring a thorough understanding of it from the outset is essential to avoid creating environments with significant security vulnerabilities that are difficult to rectify later on.

How does IAM internally work?

By default, all requests to all resources are denied. This means access has to be explicitly granted for everything.

When a request hits the AWS APIs, it goes through an internal authentication and authorization control that evaluates the requester's permissions for accessing an AWS resource by examining their attached permissions. These permissions are attached in the form of JSON documents.

In the following paragraphs, we will delve into the precise definition of those permissions and how they become associated with various identities.

Critical Concepts for AWS IAM

We must grasp the fundamental principles of IAM. This encompasses comprehending users, groups, roles, policies, and permissions. Furthermore, we should familiarize ourselves with Access Keys and Multi-Factor Authentication.

Additionally, we'll delve into how these concepts serve as the adhesive that connects all of your AWS services.

Users, Groups, and Roles

AWS IAM comes with the concept of users. They can be allocated to groups for the sake of simplifying user rights management. Each identity can be linked to one or multiple policies that indicate the permissions granted to that particular identity for specific resources.

On the contrary, roles are not linked to identities or users, but they can take on them and come with accompanying policies. Additionally, AWS services can also assume roles to ensure secure permission passing.

Roles are a powerful concept, as they allow you to grant temporary access to AWS resources without having to share long-term security credentials, such as access keys or passwords. This reduces the risk of unauthorized access and helps to improve security. Additionally, they help you to manage access to AWS resources based on job functions, rather than individual users. You'll grant permissions to a role and then allows users or services to assume the role to fulfill their duties.

Policies and Permissions

IAM policies include statements that specify which actions are permitted or prohibited, which resources the actions apply to, and under what conditions the actions are allowed or denied. IAM assesses each policy statement to decide whether to allow or deny the requested action.

Access Keys and MFA

AWS offers various ways to utilize its services, such as interactive access through the AWS management console and web browser, or programmatic access via the AWS API. The two main forms of credentials are console passwords and access keys.

• Console passwords - they allow the user to sign into an interactive session at the AWS management console. Users will be prompted for the unique 12-digit account identifier, their IAM user name, and their password. The account ID is required as IAM user names don’t have to be unique over all AWS accounts like S3 bucket names, but only per account.

• Access keys - These tools are designed to provide programmatic access to AWS through its API. You can directly submit calls to the AWS API to create, update, delete, or list resources if you have access keys. Access keys are made up of two parts: an Access Key ID and a Secret Access Key. To make using the AWS API more convenient, there are several tools available, such as PowerShell for Windows or aws-shell for Linux and macOS.

In the end, every component operates through an API. Whether you're utilizing the AWS console interface, the AWS CLI, or the AWS SDK for any programming language, your actions will be translated into API calls.

For adding another layer of security to the authentication process, you can enable Multi-Factor Authentication, short MFA. MFA allows you to merge:

• "Something you know" refers to information that you possess, such as your username and password.

• "Something you own" is a device, either virtual or physical, that generates a single-use password.

When you have MFA enabled for your user, the way you access the API using your Access Key ID and Secret Access Key will also change. You must now obtain temporary credentials using your keys and the one-time security token generated by your MFA application. This can be a bit cumbersome if you try to do it manually, but tools like Leapp drastically simplify the process for you.

IAM Is the Glue between All AWS Services

No matter what you're constructing on AWS, it's crucial to thoroughly understand and utilize IAM as a key component. While IAM is frequently employed with a haphazard "just make it work" method, it's one of AWS's most comprehensive and well-established services, ensuring the safety of your infrastructure and data.

As a metaphor, it's like the glue that binds everything together. Conversely, it could also be the missing piece that causes everything to crumble.

Identity vs Resource-Based Access

As you navigate AWS IAM, you'll encounter two policy types. These can be categorized as either identity-based or resource-based. In the following paragraphs, we'll explore the distinctions between the two and provide examples to aid in comprehension.

Identifying Resources Uniquely: Amazon Resource Identifiers

To comprehensively examine the policies, it is essential to first grasp how AWS distinguishes resources within its vast ecosystem that caters to over a million clients.

This is established via Amazon Resource Identifiers, short ARN.

ARNs have multiple uses beyond IAM, such as in AWS CloudFormation templates and AWS service APIs. They provide a secure and consistent method for specifying and granting access to resources.

Let’s have a look at the two examples above:

• An Amazon S3 bucket: arn:aws:s3:::my-bucket

• An Amazon DynamoDB table: arn:aws:dynamodb:eu-west-1:123456789012:table/mytable

The ARN prefix, arn:aws, signifies that it belongs to the worldwide AWS system (note that AWS China, or AWS CN, is a distinct entity identified by the prefix arn:aws-cn). It is followed by the service abbreviation. In our case, s3 for Amazon S3 and dynamodb for Amazon DynamoDB.

The region is specified by the next part (e.g. eu-west-1), and the account ID is specified by the fourth part (e.g. 123456789012). You may notice that certain services, such as S3, are not restricted to a specific region, despite their resources being located in one region. In such instances, the region identifier is left unspecified.

The ARN includes the resource name or identifier to specifically identify the resource. For instance, in the ARN for an Amazon DynamoDB table, the table name (mytable) comes after the table/ prefix. This enables you to distinguish the table and grant access to it through IAM policies.

Identity-Based Access

On the one hand, AWS offers identity-based policies that authorize users, groups, or roles to access resources. They come in different types:

• Managed Policies: policies that can exist on their own (standalone) and can be attached to multiple identities within your AWS account. Managed policies in turn also divide into two further categories:

  • AWS-managed policies: policies that are created and managed by AWS.

  • Customer-managed policies: policies that you create based on your requirements.

• Inline Policies: policies with a strict one-to-one relationship to an identity.

Let's take a look at a policy example that permits starting and stopping EC2 instances in every region.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"],
      "Resource": "arn:aws:ec2:*:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/groups": "developers"
        }
      }
    }
  ]
}

We have the option to link this policy to a user, group, or role to allocate those specific permissions.

By attaching the policy to a role, we have the flexibility to temporarily grant permissions to users, groups, or even AWS services.

Resource-Based Access

On the other hand, resource-based policies are based on resources and are not linked to identities, but rather to specific AWS resources, such as an S3 bucket.

These policies provide designated principals with permissions for that particular resource. Resource-based policies are essentially inline policies since they cannot exist without their corresponding resource.

Let's go through two examples of resource-based policies:

1. Amazon S3 - a bucket policy that allows you to grant permissions to resources in the bucket, such as objects and folders.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"]
    }
  ]
}

1. AWS Key Management Service (KMS) - Granting read permissions for KMS keys for a specific user while maintaining full-administrative permissions for the root user.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Admin Permissions for Root",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Read Access for KMS Keys",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/example-user"
      },
      "Action": [
        "kms:Describe*",
        "kms:List*",
        "kms:Get*",
      ],
      "Resource": "*"
    }
  ]
}

Resource-based policies are not supported by most AWS services, but there are a few exceptions. Besides S3 buckets and KMS keys, there are also SNS topics or secrets in AWS Secrets Manager. AWS offers a comprehensive catalog of all its services along with the corresponding IAM functionalities they support, all well-maintained.

Working with IAM to Manage an Organization

An AWS account comes with natural boundaries for security, access, and billing. Outside users do not have any access, and created infrastructure is solely allocated to your account and its users.

You might already understand why it's good practice to leverage those account boundaries by using multiple AWS accounts. This is not only helpful to strictly separate environments, but it can also be used to map down organizational structures to your AWS ecosystem.

AWS IAM and AWS Organizations make this possible.

AWS Organizations Key Concepts

AWS Organizations allows you to effortlessly apply your IAM permissions across multiple accounts. To achieve this, you must first comprehend the various features that come with AWS Organizations.

• The Management Account - This is the original account that was utilized to establish the organization. It possesses complete access to every AWS resource and service.

  

• An Organization - Think of this as a receptacle for numerous AWS accounts. It enables you to oversee them all in a single, centralized location utilizing the capabilities of AWS Organizations.

  

• Organizational Units - Organizational units serve as an effective means for precise management. Each unit functions as a logical container, capable of accommodating accounts and additional organizational units.

  

These features assist in the mapping of applications, projects, and the hierarchical structure of your organization within your AWS ecosystem.

Furthermore, you can limit access rights from a central location for your entire company, specific organizational units, or single accounts through the implementation of service control policies, which we will explore in the following paragraph.

Applying Service Control Policies

Service Control Policies (SCPs) allow you to restrict access to AWS resources and services. As mentioned before, they can be applied to an organization, organizational unit, or individual account.

They assist you in implementing precise permissions throughout your various accounts, enabling adherence to compliance regulations and the enforcement of rigorous security measures.

Using SCPs, you could enforce MFA usage across your entire organization, including all member accounts.

Our deep-dive article provides a hands-on approach to learning more about AWS Organizations.

IAM Best Practices

IAM provides a powerful set of tools for managing access to AWS resources, but it can be complex to configure and manage. By following best practices, you can ensure that your AWS environment is secure and well-managed.

Least Privilege and Separation of Duties

If you give users or roles too many permissions, it could result in them accessing AWS resources they shouldn't have access to. It's crucial to adhere to the principle of least privilege and only grant permissions that are necessary for users to do their job.

This highlights the need for creating customized roles that grant permissions for specific or limited tasks. It's important to avoid broad permissions or roles that are applied to multiple tasks and grant excessive access.

Multi-Factor Authentication

Enabling MFA for your root user or any other IAM user is a straightforward process. You can also mandate the use of MFA across your entire account or AWS organization by implementing policies.

Making Use of AWS Identity Center or Federation

In simpler terms, setting up users directly on AWS IAM is an outdated feature. AWS advises utilizing a specialized identity provider and solely utilizing roles to assign access to those identities.

As the name expects, an identity provider (IdP) is a service that solely focuses on managing identities. Those identities can be used across your AWS Organization by using federation.

The AWS Identity Center can act as an IdP, which means that there is no need for a third-party service to manage users and groups throughout the organization or to facilitate Single-Sign-On (SSO). Nonetheless, in larger-scale environments, it is recommended to choose a service that specializes in identity management.

Avoiding Common IAM Mistakes

In addition to the detailed recommendations listed above, numerous other common IAM mistakes are often found in both small and large projects. Among them are:

1. Not making use of IAM roles - When utilizing AWS services for your workloads, it is crucial to utilize roles with customized permissions. AWS will handle the issuance of temporary credentials to prevent any concerns about database password leaks.

2. Not rotating access keys regularly - if you require long-term access keys, they have to be rotated regularly to reduce the risk of accidental leakage.

3. Using your root for daily tasks - You should only use your AWS root user to establish your account and organization. Once that's done, it's best to lock it away because its permissions are too broad.

4. Not making use of SCPs - if you're working with multiple accounts within an organization, it's important to establish guardrails across your organization via service control policies.

5. Not making use of Permission Boundaries - another advanced feature of IAM are permission boundary policies that can be applied to roles. Those boundaries do not grant permissions on their own, but restrict the maximum permissions that can be delegated via a role.

This list is not comprehensive, but it provides a good starting point for best practices.

Extending your AWS Fundamentals beyond IAM

It is important to learn the fundamentals of AWS IAM first because it is a critical component of the AWS ecosystem that serves as a central control point for managing access to AWS resources. However, to successfully become a DevOps engineer, you need to continue to learn about other core services like Lambda, DynamoDB, or ECS as they are the backbone of many successful organizations and projects.

The book AWS Fundamentals is a great resource for learning the must-knows about the 16 most used and famous AWS services. It also includes an introduction to modern Infrastructure as Code, which is an important concept for DevOps engineers to understand.

In addition, the book includes infographics that visualize critical facts in a bite-sized manner, making it easier to understand and remember key concepts. By learning about IAM and other core AWS services, you can develop the skills and knowledge necessary to become a successful DevOps engineer in the AWS cloud.

Conclusion

AWS IAM is a critical service that is used to manage access to AWS resources. It is essential to understand the key concepts of IAM, including users, groups, roles, policies, and permissions.

By following best practices, such as adhering to the principle of least privilege and enabling multi-factor authentication, businesses can ensure the security of their AWS environment. Additionally, AWS Organizations and Service Control Policies can be used to manage an organization's AWS ecosystem effectively.

Overall, understanding and utilizing AWS IAM is crucial for maintaining a secure and well-managed AWS environment.

Has your organization scaled to operate infrastructure across multiple AWS accounts? Are you having problems accessing resources, or resources accessing on another, across multiple accounts? If so, you’ve found the right article to help you solve these issues.

In this blog post, we’ll discuss managing cross-account IAM roles at scale. IAM is a powerful, centralized service that allows organizations and users to manage their resources and define permissions across AWS. IAM allows you to manage permissions at various levels and scale access across multiple accounts and organizations. Whether it's an SCP, a user, a group, or a role, this service gives the user or organization plenty of control over access rights to various other services and resources within AWS.

Defining cross-account access

When multiple accounts exist within an organization, it can be quite challenging to define cross-account roles and policies. Depending on the use case, the complexity of the permissions and trust policies that are associated with each role may vary. Let’s define a simple use case and describe the access requirements each service that is utilized will need.

BonTriage's cross-account dilemma

This made-up organization, called BonTriage, would like to deploy a list of cloud formation templates from their staging account, ER-123456, into their production account, TR-789012. These templates are responsible for creating several resources, such as S3 buckets and EC2 instances, and configuring autoscaling groups and other networking components. The engineers, unsure of how to do this, start to research and develop a strategy for getting these resources deployed into those respective accounts. During the research and design phase, they created an example architecture diagram.

The architecture diagram contains 2 IAM roles and one CloudBuild node. The CodeBuild node, CFTDeployerNode which is in the ER-123456 account, is responsible for deploying a CloudFormation stack into the TR-789012 account. To accomplish this, the CFTDeployerNode resource assumes the IAM role called “CodeBuildRole”. This role has the right to assume another IAM role called “ResourceDeployCAR” which contains the permissions to deploy the CloudFormation stack within the account. Sounds quite simple, right? Let’s dive a little deeper to see how this is happening.

The key component that you must understand about both roles is their respective trust policies. According to AWS, the trust policy of a role defines which principals can assume the role and under what conditions. Based on that definition, the “ResourceDeployCAR” roles must be modified. An example trust policy is highlighted below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCodeBuildNodeToAssume",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::332*********:role/CodeBuildRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This trust policy allows the “CodeBuildRole” role to assume the “ResourceDeployCAR” role to deploy the stack set inside of the TR-789012 account. Without the principal of the role added to the trust policy, the role used for the CodeBuild resource would have not been able to assume the “ResourceDeployCAR” role in the other account.

For any cross-account roles or users that you create, you’ll want to ensure that your trust policy permits your other roles to assume them and their permissions sets. Policies of these roles and users are still incredibly relevant, as they ensure access to resources within the role-assumed account. In this case of the CFTDeployerNode, an example policy that would be attached to the “ResourceDeployCAR” role is highlighted below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAllCloudformationActivitites",
      "Effect": "Allow",
      "Action": [
        "cloudformation:Describe*",
        "cloudformation:List*",
        "cloudformation:Get*"
      ],
      "Resource": "*"
    }
  ]
}

With the policy document outlined, the CodeBuild role should be able to create all of the resources via CloudFormation in the other account.

Managing cross-account roles

By giving an example in the previous section, we were able to define a cross-account role that grants access to a CodeBuild resource from an account to deploy CloudFormation resources in a different account. The same pattern for IAM roles and users can be adopted and applied to several accounts across organizations in AWS. However, as the amount of cross-account roles increases, the amount of overhead for managing these roles increases as well.

To effectively manage cross-account roles, I would suggest leveraging Leapp. Owned by Noovolari, Leapp is an open-source cloud application that manages cloud credentials. As a multi-cloud credential management application, it has several key features that enable organizations and teams to easily manage IAM resources without accessing the console or entering CLI commands. Some of the key features of IAM resource management include role and user session management and credential generation and rotation.

Since we’ve given a slight overview of what Leapp is, let’s answer the question you’re probably asking: How does Leapp solve managing cross-account roles at scale? By using Leapp, one can create several profiles and link users and roles to those profiles! When you are interacting with AWS services using CLI commands and boto API calls, your machine must have a credentials file configured with all of the profiles you’d like to use. An example of what the credentials file would typically look like is highlighted below:

[default]
sso_session = my-sso
sso_account_id = 111*********
sso_role_name = readOnly
region = us-west-2
output = text

[profile user1]
sso_session = my-sso
sso_account_id = 444*********
sso_role_name = readOnly
region = us-east-1
output = json

[sso-session my-sso]
sso_region = us-east-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access

When you leverage Leapp to manage your profiles, you can quickly discern which role you’ve created a session for regardless of the IAM resource type. You can associate any kind of IAM resource with a profile and include MFA information and data in Leapp.

The image above is an example of an IAM Role and IAM User that have been created under two different profiles. The IAM User, ‘Damien’, exists under the named profile called ‘DJB Financial Corp’, whereas the DataCop role is associated with the named profile ‘DataCop’. As new roles are created, new profiles and their roles can be created/added to Leaap. If you have several roles that are associated with a profile, you can filter which role you’d like to use Leapp using the name of the profile. This feature alone makes it incredibly useful when organizations have not only created simple users, roles, and federated roles, but it can aid in managing complex cross-account roles.

If you wish to be more comfortable with working with a shell, Leapp has a CLI tool that would help you manage the profiles and IAM resources as well. If you’d like to learn more information on how to manage profiles with the CLI tool, you can read that information here: Leapp CLI - Profiles

Conclusion

Defining cross-account permissions and access can be incredibly difficult as your organization scales. Most of the time, an organization will have multiple accounts that need to share data and other components between them. When defining cross-account permissions for roles and users, you’ll want to ensure you are familiar with trust policies. These trust policies will ensure that your role or user grants the other IAM resource the right to assume it.

As the number of IAM cross-account resources grows, you’ll want to leverage a management platform like Leapp. This application has many features to help organizations manage their IAM resources by creating profiles. You can group a plethora of IAM resources into these profiles, and they do not have to be associated with a single account.

By following these strategies I’ve highlighted, you or your organization can effectively define and manage cross-account access and minimize overhead and other transitive issues.

In this authentication process, one of the most common errors you may need to confront is "response did not contain a valid saml assertion," and in this article, I want to share with you some troubleshooting advice to solve it.

Investigating a No valid assertion found in SAML response

Checking the attribute name and attribute value on your IdP

If you are on AWS (but in general), invalid SAML assertion mainly occurs when the SAML response from the IdP does not include an attribute with the Name set to https://aws.amazon.com/SAML/Attributes/Role . The attribute must also contain one or more AttributeValue elements, each with these two strings, separated by a comma:

• The ARN of a role that the user can be mapped to

• The ARN of the SAML provider

E.g.:

<Attribute Name="<https://aws.amazon.com/SAML/Attributes/Role>">

<AttributeValue>arn:aws:iam::account-number:role/role-name1,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>

</Attribute>

Here is also an example of a resolution for Okta.

Time Synchronisation issues between IdP and Service Provider

https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/Investigating a No valid assertion.htm

If the SAML IdP and SAML service provider (AWS, for example) clocks are not synchronized, the assertion can be determined invalid, and authentication fails.

A possible solution is to verify that your IdP and Service provider can share the same NTP server or prove that your server's clock is up-to-date.

Metadata.xml mismatch

Data refreshes, and upgrades can cause the certificates to be no longer trusted by one side of the Federation process or the other. Try to check and update the metadata.xml on both ends so the certificates will match again.

SAML message not properly formatted, with missing or invalid elements

https://stackoverflow.com/questions/64158310/aws-sso-your-request-included-an-invalid-saml-response

Sometimes the error occurs not only with the User attribute but in general if the message needs to include all the required information in the required format. For example:

• The message was signed, but the signature could not be verified.

• Assertion contains an unacceptable Audience Restriction.

• The assertion is no longer valid, or the message is expired, see Time Synchronisation issues between IdP and Service Provider.

• SAML response contained an error indicating that the Cloud Provider received a SAML message from an IdP with an error status code.

Remember that SAML is schema-compliant, so you must adhere to its standard when creating its XML request. Make sure to refer to this document to see all the standard tags.

Some more examples of possible typos can be:

• Not including encoding at the beginning of the XML:

<?xml version="1.0" encoding="UTF-8"?>

• Typo in the Recipient of the SubjectConfirmationData: set it to "https://signin.aws.amazon.com/saml."

• Not including an AuthStatement.

How to view a SAML response for troubleshooting

https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html

This article has several ideas to help you narrow down the exact cause of the issue. Still, I'd also like to give you some basic tips on debugging the SAML assertion you receive to find details that can point you to the root cause of your problem.

Google Chrome and Firefox

1. Press F12 to start the Developer Tools console.

2. Select the Network tab, and then select Preserve log (Persist Log in Firefox)

3. Look for a SAML Post, then view the Payload tab at the top. Look for the SAMLResponse element that contains the Base64-encoded response.

4. Copy it.

💡 Security Note: as SAML assertions contain sensitive information, I discourage you from using  online base64 decoders  and using one of these simple scripts to do it from your local terminal.

Windows systems (PowerShell):

PS C:\\>[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("base64encodedtext"))

MacOS and Linux systems:

$echo "base64encodedtext" | base64 --decode

Also, if the attributes from your Identity Provider are not encrypted, the Firefox browser SAML tracer Add-on or Chrome SAML Message Decoder can view these attributes.

Tutorials

To help you further, here are two articles from our blog where we share some hints to configure SAML with GSuite (note that concepts and properties are similar to other IdPs).

• https://blog.leapp.cloud/how-to-saml-federate-your-aws-account-with-g-suite

• https://blog.leapp.cloud/how-to-update-in-bulk-g-suite-users-custom-attributes-with-google-admin-sdk

Conclusions

In this article, we have seen how to troubleshoot a very pesky error of the SAML Federation: "Response did not contain a valid SAML assertion."

We have shown that it can occur when:

• Role attributes are not set correctly in the SAML request - IdP side.

• There is a time desynchronization between the IdP and the Service Provider.

• There is a Metadata.xml mismatch between the actors, so the certificate doesn't match.

• There are typos or an invalid SAML structure in your request.

In general, I always return to this link when I need to troubleshoot a SAML response, as the problem may lie on a different configuration depending on the IdP you're using.

This little article has been of help to all of you, and till next time, Happy SAML assertions, and see you in the next article! 😉

Worry not! If you’re a dark mode enthusiast like myself, because you use it on your IDE and all your apps, you enjoy its benefits on productivity and health, or simply you like the aesthetics of it, AWS recently released a new dark mode for the Management Console. It is still a beta, but it works with almost all services.

Let me explain how to enable it in this quick article!

How to enable dark mode in the AWS Management Console

1. First of all, access the AWS console, then click your account name in the top right corner. In the dropdown menu, click Settings.

1. The Unified Settings page will show up, and from there you will be able to see the following options. In the Display option, click Edit.

1. Now, select Dark in the Visual mode section. You can also see how it will look in the preview window on the side. Finally, click on Save settings to join the dark side of AWS!

And there you go, here’s how your Management Console home should look like. Easier on the eye, isn’t it? Remember that this is a beta feature; the most common services are already fully supporting it, but there are a couple with limited support or no dark mode yet.

Pro Tips

As a dark mode fan, this feature was one of the first we thought about while our open-source tool Leapp was in development. Besides allowing to access and manage multiple AWS accounts in a click, Leapp was also built to make the AWS console experience super-easy, quick, and smooth for DevOps.

Feel free to give it a try! And drop a star to the GitHub repository if you like it!

See you in the cloud!

Enjoy the read!

Introduction

Hello cloud fellows! Today we’ll build up on the cloud landing zone series to explore a fascinating but often ignored context… Service Control Policies! SCPs are powerful, but there are a few caveats and tricks to make them work efficiently with every different kind of IAM policy. In this blog post, we will see how the whole IAM ecosystem interacts and how we can effectively leverage the tools to deploy a strong IAM strategy in our Cloud Landing Zone.

There is a lot of ground to cover, so let’s start immediately!

I don’t want to bother you with all the details about AWS Organizations so that we can keep our focus on permissions. If that’s not the case, refer to one of the thousands of articles on the web or check THIS one I wrote.

Policies

So, let’s get the foundations covered (for the laziest of you, skip after the graph, there’s a neat bullet-point recap). Before jumping directly to the interactions, we need to understand what we have at our disposal in our IAM strategy and all the different kind of tools in IAM to make it work:

1. Identity-based policies are the most common type of policy. They are tied to IAM (Identity and Access Management) users, groups, and roles and specify what actions those entities can perform on certain AWS services.

2. Resource-based policies, on the other hand, are policies that are directly associated with an AWS resource, such as an S3 bucket or an EC2 instance. Resource-based policies specify who has access to the resource and what actions they can take. Not all AWS services support them (for a comprehensive list, check the AWS services that work with IAM page), and they are usually used for very specific scenarios.

3. Permission boundaries (PBs) are policies that define the maximum permissions that an IAM entity can have. These policies limit an entity's permissions, ensuring they cannot perform actions that exceed their authorized scope. Permission boundaries are also written in AWS policy language and can be attached to IAM entities.

4. Service control policies (SCPs) enforce restrictions on AWS accounts within an AWS organization. SCPs are hierarchical policies applied to the entire organization or specific organizational units. SCPs can be used to limit the actions that an AWS account can perform, preventing them from performing activities that are outside their authorized scope.

5. Session policies are applied to temporary credentials created by IAM roles. Session policies limit the permissions of a temporary credential set, ensuring that it cannot perform actions that exceed its authorized scope. However, they primarily work like PBs and SCPs: they do not grant permissions and are applied only for the duration of the token. For the sake of simplicity, we’ll introduce this only at the end, so for now, let’s not consider it.

The caveat

As you may be starting to get, there is a fundamental difference between those policies, and it's laid out in the diagram by the action that connects the policy to the actual permissions.

⚠️ Permission boundaries and Service control policies do NOT grant ANY permission

An Identity can access a Resource only through Identity-based and Resource-based policies. Permission boundaries and SCPs can only limit the aforementioned permissions. That means we need an Identity-based or Resource-based policy that explicitly allows permission to let the policy evaluation engine.

In short, Identity-based and Resource-based policies define who can access resources and what actions they can perform. Permission boundaries and Service Control Policies limit the scope of those permissions, ensuring that entities cannot perform unauthorized actions.

A visual representation of policy interaction

So let’s get a visual representation of our policies: start by seeing how it works in a single account, and then see how things change by adding AWS Organizations to the equation.

Yeah, I know the icons differ from the AWS framework but bear with me; I want to highlight the differences and that we’re working with fundamentally different policies.

Single account (without Organizations)

As you can see, the three elements we can leverage are Identity-based, Resource-based policies, and Permission boundaries:

We can see that while the policies going in and out of the Identity and the Resource grants access, the Permission Boundaries limit that set of permission instead.

It’s impossible to grant additional permissions through the use of Permission Boundaries.

Organization structure

When integrating the AWS Organization service, we gain the ability to use Service control policies to have better control over our environment:

The behavior is practically the same as Permission Boundaries, but we’ll see soon that it has a slight difference. So, to briefly recap:

1. AWS Identity-based policies:

   • Most common policy type in AWS.

   • Attached to IAM entities (users, groups, and roles)

   • Specify actions that entities can execute on specific AWS resources

   • Goes from Identity to Resource

2. AWS Resource-based policies:

   • Attached to an AWS resource (e.g., S3 bucket or EC2 instance)

   • Determine which users have access to the resource

   • Define what actions the authorized users can perform on the resource

   • Not all AWS services support them

   • Used in very specific scenarios

   • Goes from Resource to Identity

3. Permission boundaries:

   • Attached to IAM entities.

   • Defining maximum permissions for an IAM entity

   • Limits the entity's permissions to the authorized scope

4. Service control policies (SCPs):

   • Hierarchical policies for AWS accounts in an Organization

   • Used to restrict the actions of AWS accounts

   • Limits activities outside the scope of permissions.

5. Session policies:

   • Used with identity-based policies and permission boundaries

   • Applied to temporary credentials of IAM roles

   • Limits the permissions of temporary credentials

   • Ensures authorized scope is not exceeded

The policy evaluation flow

Behind all these definitions, a policy evaluation engine goes through all the policies we have seen before and evaluates if the specific action performed has to be allowed or denied.

Here I condensed the logic to understand the decision flow better:

It’s interesting to note that Resource and Identity-based permissions are evaluated at the center of the evaluation flow. Around them, SCPs and PBs are evaluated, which we clustered in control policies.

Aside from Resource-based and Session policies, it turns out that it’s pretty straightforward; the trick here is to focus on the edge cases.

With resource-based policies

Resource-based policies result in a deny when the Principal making the request is different than the Principal we’re granting access to through the Resource-based policy. I’ve highlighted the affected case in the schema proposed by AWS at this link.

With session policies

Even in this case, it’s simpler than it looks. Session policies kick in only when they are present.

If you’re not using them in your request, you shouldn't care, but when the time comes that you’re leveraging them, you need to remember the following:

• there is no allow → implicit deny

• there is no explicit deny → implicit deny

A side note on cross-account access

Until now, we’ve considered only access within the same account, but what would happen if we need to evaluate also cross-account access? It’s simpler than it looks: request is evaluated on policies and permission from the perspective of both the trusted and trusting account and allowed only if both are evaluated as an allow!

If you think about this, it’s more restrictive than single access. Since AWS permission starts with an implicit deny, you must explicitly set the permissions on both accounts before evaluating the request as an allow.

Permission intersections

After understanding what is involved in deciding when a request is allowed, we can move on to how they interact.

This led to two practical scenarios, one with and one without Resource-based policies. The main point here is to understand that the only case in which one’s effective permissions can exceed that of the whole intersection is when Resource-based policies are involved.

When Resource-based policies are involved, if they evaluate as an allow, you’re taking the final decision before the policy evaluation flow would evaluate Identity-based, Permission Boundaries, and Session policies. This results in permissions granted that can exceed the ones explicitly allowed by those policies.

About SCPs inheritance

The last thing to say is about Service Control Policies and the fact that they can be inherited.

Strangely, this doesn’t work as one should expect (but it’s for the better, trust me).

When one thinks about inheritance, usually in programming, but even in other fields, one thinks about getting the parent's configurations to the child. If we apply this to SCPs, Organizational Units, and accounts, one can define the SCPs at the root level and then inherit everything. Well, that’s NOT how it works.

Since DENY statements are evaluated first, in practice, only DENY statements are inherited.

If you deny a service in an SCP, there is no way to grant it in a lower-level OU or Account.

So, when an SCP is evaluated, there are actually only two SCPs that concur with the outcome:

1. The parent SCP — it’s the SCP evaluated of the next higher-level SCP; this needs to be navigated to the Root to the Organization, so it just needs to add the next layer, one step at a time

2. The current SCP — the SCP which is currently being evaluated

From this perspective, you can see that ALLOW statements are not inherited but need to be explicitly set in the SCP of the Account or Organization Unit. This is for security purposes, as we want to explicitly set the boundaries of accounts and organizational units to avoid implicit significant permissions.

Deny strategy

With a deny strategy, actions are allowed by default through a FullAccess SCP managed directly by AWS. You attach that SCP to all Accounts and OU and you need to specify what services and actions are prohibited:

This is the default configuration of AWS Organizations so that account admins can delegate all services and actions until you create and attach an SCP that denies a specific service.

The benefit of this approach is that deny statements require less maintenance because you don't need to update them when AWS adds new services, and it’s supported out of the box. You can also restrict access to specific resources or define conditions for when SCPs are in effect.

This is a great way to start for smaller organizations that need to act fast and don’t have strict requirements over governance and security.

Allow strategy

With an allow strategy, you must remove the AWS-managed FullAWSAccess SCP. Now all actions for all services are implicitly denied, and you need to create an SCP that explicitly permits only those services and actions you want to allow. This case is the same schema as the inheritance evaluation.

The benefit of this approach is that you have more control over what is allowed. Since everything is implicitly denied, this way is easier to scope down the actual boundaries of an account. Since deny permissions are inherited, you don’t have to specify it everywhere.

However, it requires more maintenance since you have to manually allow each service (and this includes new services). And it comes with some limitations on the allow statements: Resource elements can only have a ”*” entry, and they can't have a Condition.

This approach's value shines when services may not be needed by a large portion of the organization but may still be required for specific use cases. In this scenario, it’s simpler to elevate permissions and satisfy security and governance concerns while allowing flexibility and exceptions.

Just a few examples

So let’s see those SCPs in action; here, I put some examples so you can better picture what an SCP looks like in a real-world scenario.

Pipeline only account

In this case, we’ve created an SCP to deny everything except changes that run through pipelines. The use case is to create an automation-only account where no manual action is allowed, but changes are always deployed through pipelines.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptPipelines",
      "Effect": "Deny",
      "NotAction": [
        "codepipeline:*",
        "codebuild:*",
        "codecommit:*",
        "codedeploy:*",
        "codestar:*",
        "cloudformation:*",
        "iam:*",
        "s3:*",
        "logs:*",
        "cloudwatch:*",
        "cloudtrail:*",
        "codestar:*",
        "codestar-notification:*",
        "codeartifact:*",
        "kms:*",
        "tag:*",
        "access-analyzer:*",
        "codestar-connections:*",
        "ssm:GetParameter*",
        "sts:*",
        "events:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::MY-ACCOUNT-ID:role/MY-ROLE"
          ]
        }
      }
    }
  ]
}

Backup protection

In this SCP, we implemented a way to protect all backups made through AWS backup by deletion. Notice that both S3 and Backup vaults are protected and the service cannot be turned down.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3BackupDelete",
            "Action": [
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:DeleteObjectTagging",
                "s3:DeleteBucket"
            ],
            "Resource": [
                "arn:aws:s3:::MY-S3-BACKUP*/*"
            ],
            "Effect": "Deny"
        },
        {
            "Sid": "DenyBackupDelete",
            "Action": [
                "backup:DeleteBackupVault",
                "backup:DeleteBackupVaultAccessPolicy",
                "backup:PutBackupVaultAccessPolicy"
            ],
            "Resource": [
                "arn:aws:backup:*:*:backup-vault:MY-BACKUP-VAULT"
            ],
            "Effect": "Deny",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalARN": "arn:aws:iam::*:role/MY-EXECUTION-ROLE"
                }
            }
        },
        {
            "Sid": "DenyBackupTurnoffService",
            "Action": [
                "backup:UpdateRegionSettings"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Deny",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/MY-EXECUTION-ROLE"
                    ]
                }
            }
        }
    ]
}

Conclusion

Congratulations, you’ve managed to get to the end of the blog post! We’ve gone from the policy evaluation flow to the actual implementation of SCPs, passing through the understanding of all the details that concur in policy and boundary interaction.

From seeing the SCP examples, as with any governance tool, their implementation is extremely tied to how your organization is structured and works. So I truly believe this knowledge should be well internalized and widely understood within the organization.

Now you’re on your way to mastery; see you next time, and let me know how your cloud journey is going!