Cross-account access in AWS allows users from one AWS account (the trusted account) to access resources in another AWS account (the trusting account). This is particularly useful for organizations managing multiple AWS accounts, as it enables centralized management and access control without the need to create duplicate IAM users in each account.

Here's a detailed step-by-step guide to setting up cross-account access. For this example, let's assume we have two AWS accounts: Account A (trusting account) and Account B (trusted account).

Step 1: Create an IAM Role in the Trusting Account (Account A)

Log into the AWS Management Console of Account A.
Navigate to IAM → Roles → Create role.
Select “Another AWS account” and enter the Account ID of Account B. This establishes trust with Account B.
Set Permissions: Attach the policies that define what users from Account B can do in Account A.
Review and Create the Role: Name the role and review the settings. Create the role.

Step 2: Modify the Trust Relationship

Edit the Trust Relationship: Go to the role you just created → Trust relationships tab → Edit trust relationship.
Specify Conditions (optional): You can add conditions for added security, like restricting access to certain users or requiring MFA.
Update the Trust Policy and save changes.

Step 3: Grant Access to the Role from the Trusted Account (Account B)

Log into Account B.
Navigate to IAM and choose Users or Groups based on who needs access.

Attach Policy to User/Group: Create an inline policy to grant “AssumeRole” permission for the role in Account A.

Example policy:

 jsonCopy code{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Effect": "Allow",
       "Action": "sts:AssumeRole",
       "Resource": "arn:aws:iam::<Account-A-ID>:role/<Role-Name>"
     }
   ]
 }

Step 4: Assuming the Role from Account B

Use the AWS CLI or SDK: Users in Account B can now assume the role in Account A using the AWS CLI or an SDK. The command is:

 bashCopy codeaws sts assume-role --role-arn "arn:aws:iam::<Account-A-ID>:role/<Role-Name>" --role-session-name "<Session-Name>"

Retrieve Temporary Credentials: This command returns temporary security credentials.

Step 5: Access Resources in Account A

Users in Account B can use the temporary security credentials to access resources in Account A as per the permissions defined in the role.

Additional Considerations

Auditing and Monitoring: Enable CloudTrail in both accounts to log all actions taken by the assumed role.
Use AWS Organizations: For managing multiple accounts, consider using AWS Organizations for more streamlined cross-account access and billing.

Hands-on Labs and Practice

For hands-on practice, you might want to look for lab exercises provided by AWS training programs, platforms like A Cloud Guru, Linux Academy, or Qwiklabs. They offer practical scenarios to reinforce learning.
AWS Documentation and whitepapers are also excellent resources for detailed walkthroughs and best practices.

Setting up cross-account access requires a careful approach to ensure security and proper access control. Always follow the principle of least privilege and regularly review your IAM policies and roles.

References:
Video

Role of AWS STS

AWS Security Token Service (STS) plays a crucial role in temporary security credentials and identity federation, especially in scenarios like cross-account access. Here's a detailed explanation of its role and functioning:

Core Function of AWS STS

AWS STS is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users).

Key Features of AWS STS

Temporary Security Credentials: It provides short-term security credentials (access key ID, secret access key, and a security token) that can be used to access AWS services and resources. These credentials are temporary and can be configured to last from a few minutes to several hours.
Reduced Risk: Since the credentials are temporary, they reduce the risk of long-term credential exposure.
Dynamic Access Control: It allows for dynamic access control, suitable for changing conditions like user roles, tasks, etc.

Role of AWS STS in Cross-Account Access

Assuming Roles: In cross-account scenarios, a user or service in one AWS account (trusted account) can assume a role in another AWS account (trusting account) to gain access to its resources. This is done using the AssumeRole API of AWS STS.
Authentication and Authorization:
- The trusted account authenticates the user through its own mechanisms.
- Once authenticated, the user assumes a role in the trusting account via STS, which provides the user with temporary credentials.
Security Token: The security token from STS encapsulates the permissions associated with the role and the identity of the user assuming it.

How STS Works in Cross-Account Access

Requesting Credentials: The user or service in the trusted account makes a call to the AssumeRole API, specifying the ARN (Amazon Resource Name) of the role they want to assume in the trusting account.
Policy Evaluation: STS verifies that the trust relationship policy of the role allows the requesting entity from the trusted account to assume the role.
Issuing Credentials: If the request is authorized, STS returns temporary security credentials (access key ID, secret access key, session token) to the entity in the trusted account.
Using Credentials: These credentials are then used to make requests to AWS services and access resources in the trusting account, within the permissions defined in the assumed role.

Use Cases Beyond Cross-Account Access

Federated User Access: STS is used for federated user access, where users from an external identity provider can access AWS resources without having to create an IAM user for each entity.
Temporary Credentials for IAM Users: Even for IAM users within a single AWS account, STS can be used to provide temporary credentials, especially for enhanced security.

Best Practices

Least Privilege: Assign only the necessary permissions to the roles to be assumed.
Monitoring and Auditing: Use AWS CloudTrail to log all STS events to monitor the use of assumed roles and federated access.

In summary, AWS STS is a pivotal service for managing temporary, limited-privilege credentials in AWS, particularly for scenarios involving cross-account access and identity federation. It enhances security by providing a way to access resources without sharing long-term credentials and enables flexible access management across different accounts and external identity systems.

Scenario Setup:

Trusting Account (Account A): Has resources that Account B needs to access.
Trusted Account (Account B): Wants to access resources in Account A.
IAM Role in Account A: A role created in Account A with a trust relationship that allows Account B to assume this role.
User in Account B: A user who needs to access resources in Account A.

Detailed Flow with JSON Token Exchange

Step 1: Establish Trust

Create an IAM Role in Account A:
- Define a trust policy that allows entities from Account B to assume the role.
- Attach permissions to this role that specify what resources the role can access in Account A.

Example Trust Policy in JSON:

    jsonCopy code{
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {"AWS": "arn:aws:iam::<Account-B-ID>:root"},
          "Action": "sts:AssumeRole"
        }
      ]
    }

Step 2: Assume Role from Account B

User in Account B Requests Role Assumption:
- The user authenticates in Account B using their credentials.
- Then they make a call to the AssumeRole API of AWS STS, requesting to assume the role in Account A.

Example API Request (CLI, SDK, or HTTP API can be used):

    bashCopy codeaws sts assume-role --role-arn "arn:aws:iam::<Account-A-ID>:role/<Role-Name>" --role-session-name "<Session-Name>"

Step 3: Token Exchange and Temporary Credentials

STS Validates and Returns Credentials:
- AWS STS validates the request against the trust policy of the role.
- Upon successful validation, STS issues temporary security credentials.

Example of Returned Credentials (JSON format):

    jsonCopy code{
      "Credentials": {
        "AccessKeyId": "ASIA...",
        "SecretAccessKey": "wJalr...",
        "SessionToken": "IQoJb3...",
        "Expiration": "2023-01-01T12:00:00Z"
      },
      "AssumedRoleUser": {
        "AssumedRoleId": "AROA...",
        "Arn": "arn:aws:sts::<Account-A-ID>:assumed-role/<Role-Name>/<Session-Name>"
      }
    }

Step 4: Access Resources Using Temporary Credentials

Using Temporary Credentials in Account B:
- The user (or an application on behalf of the user) in Account B uses the provided temporary credentials to access resources in Account A.
- These credentials are used in API calls to AWS services, granting access as per the permissions defined in the IAM role.

Example API Call with Temporary Credentials:

    bashCopy codeaws s3 ls --profile <Profile-With-Temporary-Credentials>

Note: The profile should be configured with the temporary credentials (AccessKeyId, SecretAccessKey, SessionToken).

Step 5: Credential Expiration

Temporary Credentials Expire:
- The credentials are valid only until the expiration time returned by STS.
- After expiration, the user in Account B needs to repeat the process to obtain new credentials if continued access is required.

Security Considerations

Least Privilege: Ensure the IAM role in Account A has only the necessary permissions.
Auditing: Use AWS CloudTrail for logging all STS and role-related activities for security auditing.
Temporary Nature: The temporary nature of the credentials limits the window of opportunity for potential abuse.

Conclusion

This flow demonstrates how AWS STS facilitates secure, temporary cross-account access by exchanging JSON tokens and providing short-lived credentials. This method enhances security by avoiding the need to share long-term access keys and by strictly adhering to the principle of least privilege.

IAM Role Permissions vs Relationships :

In AWS IAM (Identity and Access Management), understanding the distinction between permissions and trust relationships in the context of IAM roles is crucial for effective access and security management. Let's break down each concept and how they interact within an IAM role.

Permissions in an IAM Role

Definition: Permissions in an IAM role define what actions and resources the role can access in AWS. These are outlined in the role's permission policies.
Purpose: They specify the level of access granted to the role. For example, a role can have permissions to read objects from a specific S3 bucket or to start and stop certain EC2 instances.
Policy Attachment: Permissions are attached to a role through IAM policies, which can be either AWS managed policies, customer managed policies, or inline policies.
Scope: The scope of permissions can be finely tuned. You can specify which AWS services and resources the role can interact with and under what conditions.

Trust Relationships in an IAM Role

Definition: Trust relationships in an IAM role define who or what can assume the role. This is specified in the role's trust policy.
Purpose: The trust policy states which principals (users, services, accounts) are allowed to assume the role. It's essentially a way to grant "trust" to an external entity to use the role under certain conditions.
Trust Policy: The trust policy is a JSON document that includes the Principal element, which specifies who is trusted. Principals can be IAM users, federated users, or AWS services.
Cross-Account Access: In cross-account scenarios, the trust policy specifies the external AWS account IDs that are allowed to assume the role.

Interaction Between Permissions and Trust Relationships

Separation of Concerns: Permissions and trust relationships are separate components of an IAM role. The trust relationship defines “who” can assume the role, while permissions define “what” the role can do.
Assuming a Role: When a principal assumes a role, they temporarily take on the permissions associated with that role. However, they must first be authorized by the trust policy to assume the role.
Security Implication: This separation enhances security. For instance, an IAM role can have extensive permissions within your AWS account, but if its trust policy does not allow an external entity to assume it, those permissions cannot be accessed by that entity.

Example Scenario

Imagine an IAM role in Account A with permissions to access a specific S3 bucket. If an IAM user in Account B needs to access this S3 bucket, Account A's role would need a trust policy that allows entities from Account B to assume it. Once the role is assumed by the user in Account B, they can access the S3 bucket as per the permissions defined in the role.

Conclusion

In summary, in AWS IAM roles, permissions define what actions the role can perform within AWS, while trust relationships determine who is allowed to assume the role. Both aspects are pivotal for managing access and ensuring security in AWS environments, especially in complex scenarios like cross-account access.

EKS cluster policy attached to the role in trust relationship:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "$oidc_provider:aud": "sts.amazonaws.com",
          "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
        }
      }
    }
  ]
}

The JSON you've provided is an AWS IAM Trust Policy, specifically configured for a scenario involving federated access using an OpenID Connect (OIDC) provider. Let's break down each part of this policy for a clearer understanding:

1. Policy Version

"Version": "2012-10-17": This indicates the version of the policy language in use. "2012-10-17" is the latest version and supports all current features of IAM policies.

2. Statement

The policy contains a single statement, which is a core element in IAM policies defining the permissions.

Effect

"Effect": "Allow": This specifies that the statement allows some actions to be performed. IAM policies can either allow or deny actions.

Principal

"Principal": { "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider" }: This part of the statement defines the principal (the entity that is allowed or denied access). In this case, the principal is a federated identity, specifically from an OIDC provider. The ARN (Amazon Resource Name) format indicates it is an identity provided by an external service that has been integrated with AWS IAM.

Action

"Action": "sts:AssumeRoleWithWebIdentity": This action refers to the AWS Security Token Service (STS) operation that allows a role to be assumed by a federated user authenticated through a web identity provider (like Google, Facebook, or a custom OIDC provider). It essentially enables external identities to assume this role and receive AWS temporary security credentials.

Condition

"Condition": { ... }: This defines the circumstances under which the policy grants permission. The conditions specify that the policy applies only if the specified conditions are true.
- "$oidc_provider:aud": "sts.amazonaws.com": This condition checks the audience (aud) claim in the web identity token. The audience is expected to be sts.amazonaws.com, which is typical for tokens meant to request AWS access.
- "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account": This condition checks the subject (sub) claim in the token. It is used to ensure that the token is associated with a specific service account within a particular namespace. This kind of condition is commonly used in Kubernetes environments where OIDC tokens represent service accounts in the cluster.

Summary of the Policy's Purpose

This policy is designed to grant an IAM role the ability to be assumed by a specific federated identity from an OIDC provider. The role can only be assumed if the web identity token has the correct audience and subject claims, ensuring that only authenticated and authorized entities from the specified OIDC provider can assume the role and access AWS resources under the permissions granted by the role. This setup is often used in scenarios where AWS resources need to be accessed by applications or services managed outside of AWS, like in Kubernetes clusters.

BhuvanChand Maddi

BhuvanChand Maddi

Cross-account access in AWS

Step 1: Create an IAM Role in the Trusting Account (Account A)

Step 2: Modify the Trust Relationship

Step 3: Grant Access to the Role from the Trusted Account (Account B)

Step 4: Assuming the Role from Account B

Step 5: Access Resources in Account A

Additional Considerations

Hands-on Labs and Practice

Role of AWS STS

Core Function of AWS STS

Key Features of AWS STS

Role of AWS STS in Cross-Account Access

How STS Works in Cross-Account Access

Use Cases Beyond Cross-Account Access

Best Practices

Scenario Setup:

Detailed Flow with JSON Token Exchange

Step 1: Establish Trust

Step 2: Assume Role from Account B

Step 3: Token Exchange and Temporary Credentials

Step 4: Access Resources Using Temporary Credentials

Step 5: Credential Expiration

Security Considerations

Conclusion

Permissions in an IAM Role

Trust Relationships in an IAM Role

Interaction Between Permissions and Trust Relationships

Example Scenario

Conclusion

1. Policy Version

2. Statement

Effect

Principal

Action

Condition

Summary of the Policy's Purpose