I'm trying to create a cloud formation template to configure a lambda in Account A with execution role Role1 to read a S3 bucket in Account B.
The execution role for the lambda already exists.
I can't seem to understand what roles to create, or policies to add. What's the best way for this use case?
CodePudding user response：
roles to create
Acc B needs to have an assumable role which allows access to S3 for principal which is Acc A.
policies to add
Lambda execution role in Acc A must have sts:AssumeRole permissions to be able to assume role from Acc B. This way you can explicitly assume the role in your lambda function in Acc A to access the bucket in Acc B.
The alternative is to setup bucket policy in Acc B to allow access from the Lambda execution role in Acc A.
CodePudding user response：
It is useful first to think of Roles as 'A user has these permissions'. However, you can only grant/deny permissions in your own account - but you can say that another account can 'assume' a role in yours.
Can be confusing I know.
in AccountLambda you need a role for the lambda. You can either use the Inline Policy (ie it was inside it, this is not recomended) or you can craft a new policy and attach it to the role (Policies are re-usable chunks of permissions that can be attached to multiple roles to give the same permissions to multiple users/resources).
One of these policies has to give Allow to whatever s3 actions you want this lambda to have, with a Resource filed of the s3 bucket uri. This is saying 'Hey, I can use these actions on this bucket'
In AccountBucket you have the bucket.
It needs a resource policy this is a single policy that attaches directly to the bucket not to a role - and is unique for some resources. This Resource Policy must give Allow Access to whatever actions you want to have and a Principle of the at the very least the arn up through your account # of AccountLambda with *s for region and resources. It is much better to be more specific, using far less wild cards.
Do note, that a resource policy is structured similarly and works the same, but is not the same as an identity policy - resource policies go directly on the resource. Identity Policies are attached to Users directly, or as is best practice, to a re-usable Role which is attached to a User or service Resource (such as lambda)
You should limit these allowances to only exactly what you need to have, but also not that if you have an Identity Policy giving access to a resource with a Resource Policy that gives said identity permissions, the sum of the combined policies is whats allowed, excepting any explicit denials.
Also note! This is unique for s3 because s3 are global resources. All other resources are only available in your account/region and in order to use them you have to assume a role within that specific account/region that has access to them.