Background:
My application reads from a AWS SQS queue. I have all my AWS Resources under one AWS account [not IAM user accounts but main AWS root account].
Question:
I have to access the SQS queue which is created under an AWS account that is different from account for all my AWS resources. My question is will this work.
I only have one account to experiment with and cannot test the scenario my self.
Any help is appreciated.
Cheers.
Yes, permission can be granted to allow a different AWS account to push messages to your SQS queues.
See: Amazon SQS Policy Examples
It is simple to create another AWS account if you wish to test this process. You can even link your accounts via Consolidated Billing. There is no charge for an additional account.
Yes its possible:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies-access-policy-examples.html
You just specify correct policy!
For example:
{
"Version": "2012-10-17",
"Id": "UseCase2",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333",
"444455556666"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2",
"Condition": {
"DateLessThan": {
"AWS:CurrentTime": "2009-06-30T12:00Z"
}
}
}]
}
Enjoy!
Related
Like connecting Lambda to SNS, for example.
I tried setting up a SNS TopicPolicy that allows publishing to SNS from my VPC cidr group. This didn't work and required me to make a SNS Publish action role and attach that to the Lambda instead.
I would have guessed that the action denial was on the service, and not the requestor, but that doesn't seem to be the case.
It looks like this behavior just depends on the service.
In the case of SNS, the default permission is to allow access to the topic from all services in your account: Example cases for Amazon SNS access control. I agree with you that this important point should be a bit more obviously stated..
Amazon SNS grants a default policy to all newly created topics. The default policy grants access to your topic to all other AWS services. This default policy uses an aws:SourceArn condition to ensure that AWS services access your topic only on behalf of AWS resources you own.
Here's what the default policy looks like if you're curious. Notice that the Principal is *.
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:Publish",
"SNS:RemovePermission",
"SNS:SetTopicAttributes",
"SNS:DeleteTopic",
"SNS:ListSubscriptionsByTopic",
"SNS:GetTopicAttributes",
"SNS:AddPermission",
"SNS:Subscribe"
],
"Resource": "arn:aws:sns:XXX:XXXX:testTopic",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "XXXX"
}
}
}
]
}
With Lambda, however, you need to explicitly grant access permissions when working with other services.
I have a "root" account.
I created an "admin" account which has all the right.
I created an account "dev" and I want it to only have acces to certain services:
s3
dynamoDB
cloudWatch
API Gateway
Lambda
Cognito
So I created a policy with the aws console editor and I gave full access to theses ressources and allows everything, it gave me this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:*",
"apigateway:*",
"lambda:*",
"dynamodb:*",
"cognito-idp:*"
],
"Resource": "*"
}
]
}
Looks good to me (not specific enough but good for a beginner).
Problem: I created db, lambda, api gateway, etc... but I can't see the services with this, which autorisation should I give for the "dev" role to see the items in the AWS console ?
I found it, I only needed to switch my region in the top right corner of the console. (shame on me)
AWS documentation has examples of different SNS access control configurations.
There are two similar configuration examples:
The first one allows to publish notifications from another account's S3 bucket to SNS topic:
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-2:111122223333:MyTopic",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "444455556666"
}
}
}
The second one allows to publish notifications from another account's SES email to SNS topic:
{
"Effect": "Allow",
"Principal": {
"Service": "ses.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2:444455556666:MyTopic",
"Condition": {
"StringEquals": {
"aws:SourceOwner": "111122223333"
}
}
}
The difference is that the first example uses aws:SourceAccount and the second one uses aws:SourceOwner.
The docs has a dedicated paragraph called "aws:SourceAccount versus aws:SourceOwner" but the distinction between these two statements is stil unclear to me.
Could you please clarify the difference between aws:SourceAccount and aws:SourceOwner policy statements?
The difference can be seen only when the owner of a resource is different from the account that the resource belongs to. It's an advanced setup. Here is an excerpt from the official doc that gives an example of this kind of setup.
... it is possible for another account to own a resource in your account. For example, the trusting account might allow the trusted account to create new resources, such as creating new objects in an Amazon S3 bucket.
Source
1. SourceOwner is used for giving access to other AWS Services from a specific account
For example, we want to define a policy that allows only SES from the account 111122223333 to publish messages to the topic 444455556666:
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"Service": "ses.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2
:444455556666:MyTopic",
"Condition": {
"StringEquals": {
"aws:SourceOwner": "111122223333"
}
}
}
]
}
2. SourceAccount is used for giving IAM roles access from an account to the topic.
For example, we want to define a policy that allows only the account 444455556666 to publish messages to the topic 111122223333:
{
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-2
:111122223333:MyTopic",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "444455556666"
}
}
}]
}
Now for case #1, if you have only 1 account with you, it doesn't make sense because SES will use the same account as the SNS. But if you have more accounts, it brings a benefit in which you only allow SES of a particular account to send messages to your topic.
Hope it helps. If it is not clear, pls put comments, and I will try to explain more.
Putting more information to get things more clear.
Taking an example of S3 send SNS message.
For this case, AWS will use the credentials of an internal S3 account and makes a call on behalf of your account, NOT from resource. Because of that, we need to use the aws:SourceAccount to perform validation in policy.
Taking an example of SES send SNS message.
For this case, AWS will use the credential of an internal S3 account and make a call on behalf of your resource, NOT from account. Because of that, we need to use the aws:SourceOwner in policy.
I would recommend you refer to case by case from documentation to understand which one you need to use. But I do hope you understand the differences between the 2 of them now.
The difference is as others have described. It might be worth noting this from the GitHub issue:
https://github.com/awsdocs/iam-user-guide/issues/111#issuecomment-1252880839
We don't plan to document aws:SourceOwner.
aws:SourceAccount was introduced as the preferred replacement.
So I would suggest using only aws:SourceAccount going forward.
In an attempt to further tighten the security of our solution we are now looking at the used SNS topics and SQS queues. All our components live in the same AWS account.
For starters we want to restrict the access to the SQS queues based on IP. So only requests coming from our NAT Gateway IP will be allowed. We don't allow anonymous access to our SQS queues.
But there seems no way to achieve this as the creator of the SQS queues - the AWS account id - has access per default. So you can't create an effective permission for another user in the same AWS account id. As this newly created user, user2, will fall under the same AWS account id, with the same set of permissions.
Am I correct in my understanding that all users in the same AWS account id have access per default to all created SQS queues as long as their IAM policy permits it? And is my assumption right that the same behavior goes for the SNS topics?
Below is the policy I would like the implement. Beside this policy I have no other policies active for this SQS q. But it is not honoring the source IP condition. I still can connect from everywhere when I use a correct AWS access key/secret combination. Only when I set the AWS principal to * - everyone - the policy seems effective.
{
"Version": "2012-10-17",
"Id": "arn:aws:sqs:eu-west-1:4564645646464564:madcowtestqueue/SQSDefaultPolicy",
"Statement": [
{
"Sid": "Sid1589365989662",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::4564645646464564:user/user2"
},
"Action": [
"SQS:DeleteMessage",
"SQS:SendMessage",
"SQS:ReceiveMessage"
],
"Resource": "arn:aws:sqs:eu-west-1:143631359317:madcowtestqueue",
"Condition": {
"IpAddress": {
"aws:SourceIp": "1.1.1.1"
}
}
}
]
}
Reference:
Using identity-based policies with Amazon SQS - Amazon Simple Queue Service
Using identity-based policies with Amazon SNS - Amazon Simple Notification Service
Amazon SQS
Amazon SQS has the ability to define Amazon SQS policies. These policies can be used in addition to IAM policies to grant access to a queue.
For example, a policy can be added that permits anonymous access to a queue, which is useful for external applications to send messages to the queue.
Interestingly, these policies can also be used to control access to the queue by IP address.
To test this, I did the following:
Created an Amazon SQS queue
Used an Amazon EC2 instance to send a message to the queue -- Successful
Added the following policy to the SQS queue:
{
"Version": "2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AnonymousAccess_AllActions_IPLimit_Deny",
"Effect": "Deny",
"Principal": "*",
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:ap-southeast-2:xxx:queue",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "54.1.2.3/32"
}
}
}
]
}
The IP address is that of my Amazon EC2 instance.
I then tried send a message to the queue again from the EC2 instance -- Successful
I then ran the identical command from my own computer -- Not successful
Therefore, it would appear that the SQS policy can override the permissions granted via IAM.
(Be careful... I added a policy that Denied sqs:* on the queue, and I wasn't able to edit the policy or delete the queue! I had to use the root account to delete it.)
Amazon SNS
I managed to achieve the same result with Amazon SNS using this access policy:
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:ap-southeast-2:xxx:topic",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "54.1.2.3/32"
}
}
}
]
}
On AWS we've implemented functionality that AWS lambda pushes message to AWS queue;
However during this implementation I had to manuall grant permissions to AWS lambda to add message to particular queue. And this apporach with manual clicks not so good for prod deployment.
Any suggestions how to automate process of adding permissions between AWS services (mainly lambda and SQS) and cretate "good" deployment package for prod env ?
Each Lambda function has an attached role, which you can specify permissions for in the IAM dashboard. If you give the Lambda functions' role the permission to push to an SQS queue, you're good to go. For example, attach this JSON as a custom role (see http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html):
{
"Version": "2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement":
{
"Sid":"Queue1_SendMessage",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:444455556666:queue1"
}
}
You can use asterisks to give permission to multiple queues, like:
"Resource": "arn:aws:sqs:us-east-1:444455556666:production-*"
To give sendMessage permission to all queues that start with production-.