Understanding Trust Relationships in AWS for Cross-Account Resource Access

What is AWS?

To understand what is trusted relationship, we first need to understand what is AWS (Amazon Web Services) within the context of cloud computing, which is a platform that provides a wide range of cloud-based services including computing, storage, database, networking, security and many more. With this in mind, AWS provides to its customers flexible, scalable and cost-effective ways to access computing resources and build applications on their own, specially because AWS operates on a "pay-as-you-go" model.

How to manage security in AWS?

Security in AWS is based on the shared responsibility model, which is exactly what the name implies, both AWS and it's customers are responsible for different aspects of security.

Responsibilities:

AWS

Is responsible for the security of the underlying infrastructure, including the physical data centers, servers, networking and storage.

Customers

Are responsible for securing their own data and applications that they run on AWS.

Main AWS tools for security control to help it's customers:

In this article, we are not going in depth about every tool of the following, but it's important to display them:

• For network security: AWS provides a Virtual Private Cloud (VPC) that enables customers to isolate their resources in a private network and, within the VPC, customers can configure security groups, network ACLs, and other network security features to control traffic to and from their resources.
• Identity and Access Management (IAM): IAM enables customers to manage access to their AWS resources by creating and managing IAM users, groups, and roles, also providing enhanced security by implementing MFA, which we will see with more details.
• Encryption: AWS provides several encryption options to help customers protect their data, including server-side encryption, client-side encryption, and AWS Key Management Service (KMS)
• Automated security features: AWS has built-in security features like Amazon GuardDuty.

IAM

AWS Identity and Access Management (IAM) is a service that enables you to manage access to AWS resources. IAM provides centralized control and management of AWS resources, including users, groups, and permissions. It allows you to create and manage IAM users and groups, which can then be granted permissions to access AWS resources. IAM also enables the creation of roles, which are used to delegate permissions to AWS services and resources.

IAM works by creating and managing access keys for users, which are then used to authenticate requests made to AWS APIs. With IAM, you can create policies that define permissions for individual users, groups, or roles, controlling who has access to what resources in your AWS account. IAM also supports multi-factor authentication (MFA), which provides an extra layer of security by requiring users to provide an additional authentication factor, such as a one-time password, in addition to their username and password.

IAM is essential for securing AWS resources because it allows you to control who has access to your resources and what actions they can perform. By using IAM to manage access to your AWS resources, you can ensure that only authorized users have access, reducing the risk of unauthorized access or data breaches.

IAM Roles

An IAM role is an AWS identity that has permissions to access AWS services and resources. Unlike an IAM user, a role does not have permanent credentials, but it can be assumed by a trusted entity, such as an IAM user, an AWS service, or an external identity federated through an identity provider. Roles are commonly used to grant permissions to entities that are outside of your AWS account, such as third-party applications or AWS services running on other accounts. By assigning roles to resources, you can ensure that only the appropriate permissions are granted to access those resources.

Example: You just deployed a brand new lambda function, which means that a new role was created (respecting the least privilege principle) and attributed especifically to that function, normally, if you're deploying a new function from scratch, it's permission role will have a basic execution role that allows lambda invocations and writing logs on an specific Cloudwatch log group, which is another AWS service that allows the user to monitor resources execution.

Your code might look something like this:

The generated role should look like this:

You can see that this role has a single permission policy, which has basic logging permission:

As you can see, a role policy has an object structure, which defines what resources and what permissions an specific resource has access to.

To see which role is attributed to your lambda you can check your function's configuration tab:

This execution role, basically, determines what that lambda is allowed to do and you can give it more permissions as long you need.

Trust Relationships

Now that we understood what is a role and know how to manipulate role permissions, we have to understand this other role concept.

Basically, trust relationships is an invitation list, it defines what other entities can have access to a specific resource. As you can see above, you can have multiple trusted entities that can be other resources in other accounts or specific user, as a developer, for example, if you want do locally test something that needs access to AWS, your configured IAM User, that you can manage once you have set up AWS CLI.

With this in mind, if we wanted to grant access to our lambda function so I could test it locally with my IAM User credentials the trust policy document would have the following element added:

And if we wanted another account to have access we would have to create a role, or use one with the permissions you need and insert it's ARN in the same trust document, as the following:

It is important to notice that you can have multiple entities as trusted, but you have to change the structure of the AWS object key to an array of strings, also notice that the ARN structure have to be respected in order for it to work properly.

Other important element is that every entitiy has to have the permission to perfom the assume role action, which is an AWS Security Token Service (STS) feature.

Intuitively, we can read the policy document like this:

"The IAM user 'juan' and the role 'test', in the account '22222222222', are allowed to perform the AssumeRole action"

After assuming role

Imagine that you assumed a role using the "test" role in the account "22222222222", all it's previous permission will be "replaced" by the assumed role permissions. With this being said, remember to always manage your policies correctly focusing on the least priviledge principle and be carefull with your credentials, if they are compromised, anyone that got them will have access to any resources that gave trust to it. Additionally, its crucial to protect your AWS credentials and rotate them regularly to reduce the risk of unauthorized access to your resources.