Reputation: 121
We own an AWS Account, account A. We rely on an external team to publish messages to their SNS topic, which is in their account B. We use an SQS queue in account A to subscribe to the SNS topic in account B. Account A has been whitelisted by the owner of account B to subscribe to the SNS topic.
Now, we would like to subscribe to the SNS topic in Account B for multiple (new) accounts. However, the team that owns account B does not have the capacity to manually whitelist the many accounts we will be creating.
Is there a way for us to delegate or proxy permissions from account A to all the new accounts that we are creating, via something like an IAM Role created in account A?
Upvotes: 1
Views: 9297
Reputation: 269081
If you can't rely on the owners of Account-B
to do anything for you, then your only option would be:
Topic-A
) where you can manage subscriptionsTopic-A
Queue-A
, so that any message sent to Queue-A
will be re-sent to Topic-A
Topic-A
as if it was Topic-B
This way, you can use your existing SQS queue (Queue-A
) as a 'relay' to a new SNS topic (Topic-A
) under your control. You would also need to change your current apps that consume from Queue-A
to consume from a new queue that is subscribed to Topic-A
.
Upvotes: 0
Reputation: 269081
Your current situation is:
Queue-A
) in Account-A
owned by youTopic-B
) in Account-B
owned by somebody elseTopic-B
that allows Account-A
to subscribe to the topicThe above has worked well.
New requirements:
Account-C
and Account-D
to subscribe to Topic-B
Account-B
does not wish to modify the permissions on Topic-B
to allow these subscription requestsSolution
Instead of Account-C
and Account-D
sending a Subscribe()
request, ask the owner of Topic-B
to directly subscribe the new queues.
You say that "the team that owns account B does not have the capacity to manually whitelist the many accounts we will be creating."
This is based on the idea that Account-C
and Account-D
should, themselves, send the Subscribe request to Topic-B
. Instead, I am recommending that you provide the ARNs of Queue-C
and Queue-D
to the team that owns Topic-B
and ask them to add these queues as subscribers. This does not require any change to the permission policy on Topic-B
.
However, a couple of things to note:
Queue-C
and Queue-D
will need to confirm the subscription. The easiest way to do this is to view the initial message sent to the queue after being subscribed to the topic, copy the subscription URL shown in the message and then paste it into a web browser. This is a one-off process.Queue-C
and Queue-D
will need to add permission to allow Topic-B
to send a message to their queue. You probably have this in place already for Queue-A
. The policy would look like:{
"Version": "2012-10-17",
"Id": "arn:aws:sqs:ap-southeast-2:ccc:my-queue/SQSDefaultPolicy",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:ap-southeast-2:ccc:my-queue",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:ap-southeast-2:bbb:their-topic"
}
}
}
]
}
See also:
Upvotes: 1
Reputation: 415
The problem is that account B is trying to give permission to a specific user of account A. Like you mentioned, this can be an issue if you need to setup multiple accounts.
You can solve this in multiple ways.
Please note that if you are going with solution #1 that any IAM user in account A will be able to access the SNS resource. If multiple applications are running in account A this could be an issue.
Upvotes: 1