I have a SQS in AWS Account A,
I have a Lambda in AWS Account B
I want to restrict only one particular resource(Lambda in Acc B) to be able to send message to SQS in account A.
I found some articles where we can give access to a user/user-group from different account to be able to do it. But I need more restrictions for my use case, and want to allow only 1 particular resource(Lambda, ARN is known) from Account B to be able to send message to 1 particular resource(SQS) in Account A
Is it possible to allow a particular resource(Not user/user-group) to perform asked functionality in a different AWS account?
If yes, how?
Related
I have two accounts A and B. I have a service in Account B that writes its logs to CloudWatch. In account A I have a AWS lambda that periodically needs to run a CloudWatch insights query to retrieve logs that match a pattern.
I can't seem to find a way to setup permissions for this or how to make a cross account cloud watch query from Lambda in Account A to CloudWatch logs in Account B. Is this even possible? If so, how?
You can do it, using cross-account access IAM role, assuming the role from the B account.
A good detailed explanation with examples can be found here.
Essentially, you have to assume a role from account B which allows your Lambda function in account A to access certain resources in account B. In the trust policy of the IAM role your AWS account A ID has to be set, so your Lambda can access resources based on what the account B policy allows.
I have a lambda function in Account A which will retrieve data from a source. This lambda will then need to trigger off a lambda in Account B in order to pass this data to it which then will be uploaded to DynamoDB.
I understand there will be some sort of cross-account-permissions required but am a little unsure if i need to allow these permission in Account A or Account B. I can see on AWS examples of triggering a lambda from an S3 bucket but that's not helping with what I want to do.
I could potentially have an API Gateaway in the middle for Lambda A to interact with Lambda B but that's just adding an extra resource that's not really required.
Your AWS Lambda function in account A would call the Lambda.invoke() method in the AWS SDK for whatever programming language you are writing the Lambda function with.
I understand there will be some sort of cross-account-permissions
required but am a little unsure if I need to allow these permission in
Account A or Account B
Account B Lambda is the one being called, so Account B has to give permission to Account A to make that call.
Here you got an example of cross-account permissions with lambda function: https://yogeshnile.cloud/configure-a-lambda-function-to-assume-an-iam-role-in-another-aws-account-e005e7533a71
Trigger Lambda in Account B from Lambda in Account A -> Lambda.invoke()
Btw, you don't need the lambda function in account B - you can add permissions to your DynamoDB table to assumed role, so your lambda from account A will be able to write data directly into DynamoDB on account B.
Just wondering if anyone has done encountered the following use case:
Account A has a step functions state machine
Account B has a DynamoDB table
Allow the state machine from Account A to PutItem into DynamoDB table in Account B
I know if we use Lambda with step functions, it allows resource based policies and we can allow "Principal" in Lambda as the state machine arn from another account and execute the lambda function in Account B from a state machine in Account A.
But DynamoDB does not support resource based policies, is there a way to deploy a CloudFormation template where we create a DynamoDB table with a policy/permission that allows a state machine from another Account PutItem in it?
You have the gist of it, but are missing a small element that makes it possible.
Account A - contains:
Lambda that is part of a State Machine
Role A
Account B - Contains:
DynamoDb
Role B
You set up the lambda with Role A. You give Role A policy to assume Role B - you are not giving Role A any dynamo permissions, nor setting any resource based permisisons on the Dyanmo
You set up Role B with the ability to be assumed by Role A, and with DynamoDB access permissions.
You can now assume role B using your SDK of choice (sts) and resolve the security credentials, store them, and use them for your DynamoDB sdk calls inside your lambda in account A.
This is entirely possible, but one of the major drawbacks is that you have to be pretty explicit with cross account role arns - and if one side changes their arns, the system breaks. It is safer (and better in some ways) to set up an API with some basic CRUD operations to the Dynamo, and have the other account call it - unless you're trying to shave miliseconds this is generally good enough.
Consider 2 AWS accounts A ( Other team ) and B ( Mine )
For my use case, I have to poll to queues in A's AWS account for payload and perform database operations in B.
To do this, I have a role created in B having access to my databases + A's account ID as trusted relationship.
Likewise A has created a role for granting access to queue in A + added B as trusted relationship.
Code for doing all the polling + database action will reside on EC2 in my account ( B ).
Now how do I consume payloads and perform operations from a role's perspective. Is my understanding correct?
Assume role A
Poll to provisioning queue, get the JSON payload from SQS
Assume role B
Perform database operations in Oracle RDS
Assume role A
Return back the response to response SQS
Start polling again on provisioning queue SQS
FYI : I am performing the above operations using Python + Boto3
Instead of assuming roles, you can grant Cross-Account access to the queues in Account A to the user/role in Account B.
In your case, grant it to EC2 instance role and then you'll be able to do all the required operations from within the instance without any "Assume role" tricks.
You don't say which programming language or SDK you are using, but essentially you can create two client/service objects, one leveraging credentials from role A and the other from role B. Then simply make API calls using the appropriate client/service object.
Using boto3, for example:
sqs_accounta = boto3.client(
'sqs',
region_name='us-east-1',
aws_access_key_id=xxx,
aws_secret_access_key=yyy,
aws_session_token=zzz
)
rds_accountb = boto3.client(
'rds',
region_name='us-west-2',
aws_access_key_id=aaa,
aws_secret_access_key=bbb,
aws_session_token=ccc
)
Pretend for a moment that everything was happening in your own account (Account-B).
You would give a set of credentials to your code (either an IAM User or, if the code is running on an Amazon EC2 instance, you would assign an IAM Role to the instance) that it can use to access the necessary resources in Account B. So, no problem there.
The only additional requirement is that you wish to access Amazon SQS in Account-A. It so happens that you can add permissions directly to an Amazon SQS queue that grants cross-account access.
See: Basic Examples of IAM Policies for Amazon SQS - Amazon Simple Queue Service
So, you do not actually need to assume any roles. Just use the normal credentials that are assigned to your code, and add permissions to the SQS queue to allow that particular IAM User or IAM Role to use the queue.
I am wanting to share a Lambda Layer with someone and by doing so I will give them it's ARN which will contain my AWS accounts 12 digit ID.
Is there any risk associated with this?
I'm assuming you trust the party you're sharing the Lamda ARN with.
The risk of sharing your account ID is limited to what permissions you have granted for services.
The AWS Account Identifiers documentation states that:
The AWS account ID is a 12-digit number, such as 123456789012, that you use to construct Amazon Resource Names (ARNs). When you refer to resources, such as an IAM user or an Glacier vault, the account ID distinguishes your resources from resources in other AWS accounts.
Someone you've shared the account ID with could manipulate ARN's but without permission to access that resource there is no issue.
Bottom line, if you have tight controls that limit external access to resources (in your case the Lambda layer) you should be fine.
While it is generally not recommended to publish your Account ID (eg in StackOverflow questions), it is not terrible if other people know it.
The security of your AWS services is tied to credentials, not the account ID.
Knowing your account ID simply makes it easier for attacks to attempt to probe your account, especially if they know some of the services you are using. For example, they could look for publicly accessible Amazon SQS queues, knowing that they belong to your account.
If you are intentionally working with other people who wish to tie-in to your account, you can certainly share the ARN.