A recent project involved connecting a service hosted on a third parties AWS cloud to our AWS cloud. The service needed to be able to read secrets from Secrets manager, and be able to read/write files to S3.

To do this you need to setup a cross account role that the principal (the third party) can assume, which then allows it to act on resources in “Trusting” account (my cloud) without having to share long-lived access credentials. Below are a few notes on how cross account roles actually work.

Principal (trusted account): The account that needs to access resources in the “Trusting” account.

“Trusting” account: The account that owns the resources to be accessed by the Principal.

Trust policy: The trust policy defines which AWS accounts are allowed to assume the role.

Access policy: Resource based policy which determines which actions and resources are allowed when the principal assumes the role

IAM Role: The role that will be assumed by the principal. It will combine the trust policy and access policy which will grant the principal access to the defined resources.

Enough talking wheres the code

Read/Write S3 access policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListObjectsInBucket",
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::bucket-name"]
        },
        {
            "Sid": "AllObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object",
            "Resource": ["arn:aws:s3:::bucket-name/*"]
        }
    ]
}

The trust policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "<arn-of-principal>"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

With those policy documents attached to a new IAM role in the trusting account we are good to go. The third party service would then specify this role as a parameter when calling, say the boto3 API.

Behind the scenes, the principal initiates an AssumeRole API call to AWS STS (Security Token Service) – this call is validated according to the trust policy (are you who is defined in the policy?) if yes – it passes a set of temporary credentials and a session token to the principal that grant it access to operate on resources.

This is far more secure and easy to manage than generating an IAM user and a set of long lived AWS creds for each service that needs to access resources.