I have a SQS setup in AWS with an access policy which allows another account's SNS to push message,
and an instance with an IAM role allowing the instance to communicate with the queue.
I found that if I apply the access policy of SQS, the instance cannot access the SQS. Removing it, the instance can work with the queue.
Is there an explanation which can explan this?
Remove the access policy from the queue, works;
SQS Policy as following:
{
"Version": "2012-10-17",
"Id": "sqspolicy",
"Statement": [
{
"Sid": "First",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "${module.elmo-s-rem-sqs-user-sync-service.primary_queue_arn}",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "${local.pivot_topic_arn}"
}
}
}
]
}
Have a tried by removing the Principal part, that could let the simulator pass. But the sns couldn't publish message any more.
Related
I have 2 different buckets.
One is able to attach Amazon SQS to event notification and the second doesn't.
SQS permissions is broad enough. It's smth with S3 bucket. But I can't figure it out.
There are no "Deny" clauses in bucket policy.
There are several additional ACL though...
This is my Access Policy stored in SQS:
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "*",
"Resource": "*"
}
]
}
This is the error:
Yes, I have seen this before.
You must create an Access Policy on the Amazon SQS queue to permit access by the Amazon S3 bucket.
Here is a sample policy from Granting permissions to publish event notification messages to a destination - Amazon Simple Storage Service:
{
"Version": "2012-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": [
"SQS:SendMessage"
],
"Resource": "arn:aws:sqs:Region:account-id:queue-name",
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:*:*:awsexamplebucket1" },
"StringEquals": { "aws:SourceAccount": "bucket-owner-account-id" }
}
}
]
}
See also: Walkthrough: Configuring a bucket for notifications (SNS topic or SQS queue) - Amazon Simple Storage Service
I contacted AWS Support. There provided undocumented details:
So, each time an S3 event is edited or saved, there will be validation
of the current destinations since the PutBucketNotification will
replace the existing notification configuration and not update it.
So I had another legacy S3 event that didn't have correct permissions. I removed it, and everything is working right now. Thank you to all who tried to help :)
I am trying deliver a message from an unencrypted SNS topic to an encrypted SQS queue following this guide. I was able to complete the "Configure KMS permissions for AWS services" step, but I am having trouble with the "Configure KMS permissions for producers
" step. I have created the IAM role, however attaching this role to my SNS topic is where I am specifically confused. Here are some questions I have which my own research was unable to answer:
Can an IAM role be attached to a specific item (SNS topic, SQS queue, etc...)? If not, what other way is there to grant permissions to a specific item?
When the instructions mention "producer", is this referring to the SNS topic or the AWS account which owns the SNS topic?
Any and all help is greatly appreciated.
Edit:
Here is my current AWS KMS key policy:
{
"Version": "2012-10-17",
"Id": "key-consolepolicy-3",
"Statement": [
{
"Sid": "Allow administration of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${aws_account_id}:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow SNS to use KMS",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}
Whenever I add the following statements to my KMS key policy in the Statement list, I get the error "MalformedPolicyDocumentException - Policy contains a statement with no principal":
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "${kms_customer_managed_key_arn}"
},
{
"Effect": "Allow",
"Action": [
"sqs:SendMessage"
],
"Resource": "${sqs_queue_arn}"
}
If not, what other way is there to grant permissions to a specific item?
The permissons from the link are attached to your KMS CMK key policy.
When the instructions mention "producer", is this referring to the SNS topic or the AWS account which owns the SNS topic?
The producer is anyone or anything that sends messages. It can be a lambda function, an ec2 instance or IAM user/role. In that case you give the producer permissions to sendMessage and use the KMS key. For lambda it would be in lambda execution role, for instance it would be in an instance role.
I am trying to configure the SQS policy for a queue to authorize all principles of an account to send messages to this queue, according to the documentation here:
{
"Version": "2012-10-17",
"Id": "sqspolicy",
"Statement": [
{
"Sid": "Sqs policy1",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789:root"
]
}
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:eu-west-1:123456789:my_queue"
}
]
}
Will this allow any principle of this account to send messages to my_queue or will it only allow the root user?
Or should I use the below policy with a condition instead?
{
"Version": "2012-10-17",
"Id": "sqspolicy",
"Statement": [
{
"Sid": "Sqs policy1",
"Effect": "Allow",
"Principal": {
"AWS": "*"
}
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:eu-west-1:123456789:my_queue"
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "123456789"
}
}
}
]
}
TIA
The documentation says:
When you use an AWS account identifier as the principal in a policy, you delegate authority to the account. All identities inside the account can access the resource if they have the appropriate IAM permissions attached to explicitly allow access. This includes IAM users and roles in that account.
According to this, your first approach will allow all of your users to send messages.
Only first policy is valid. The second policy will not work, the way you may think. The reason is that aws:SourceAccount is only used for service-to-service requests, not IAM users or roles. The most common example of when aws:SourceAccount is used is for S3:
For example, when an Amazon S3 bucket update triggers an Amazon SNS topic post, the Amazon S3 service invokes the sns:Publish API operation. The bucket is considered the source of the SNS request and the value of the key is the account ID associated with the bucket.
Send-messages requests made by IAM users/roles in the second account will be denied because for these entities there is no aws:SourceAccount.
I have a NodeJS application that publishes message to AWS SNS topic string and a AWS SQS subscription for the same. On the SQS console, I can see the published message. However, I am not clear with the access policy of the SQS queue.
This answer mentions the use of "Principal": "*" - but, that is very broad. One could probably use "Principal" : {"AWS": "*"}; but, that isn't narrow either.
{
"Version": "2012-10-17",
"Id": "Policy1607949016538",
"Statement": [
{
"Sid": "Stmt1607949012567",
"Effect": "Allow",
"Principal": "*",
"Action": [
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:ap-south-1:463113000000:orders"
}
]
}
Questions
While delivering a message to SQS queue, as a result of subscription, which user is in effect? Same as the one who published to the topic?
I could get the messages to flow into the queue only when I used "Principal" : {"AWS": "*"}. So, how should I define a restrictive policy such that messages are written to queues only as a result of subscription?
What is the equivalent in the AWS SQS CLI to create a queue with "Principal" : {"AWS": "*"} permissions?
The only user that matters is the one that qualifies for the policy as defined for subscription and SQS access policy.
The Condition in policy document can make the overall policy restrictive. See example below.
Adding SQS Permissions with conditions using AWS CLI Command
Example policy document restricting access to account ID.
{
"Version": "2012-10-17",
"Id": "Policy1607960702002",
"Statement": [
{
"Sid": "Stmt1607960701004",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:ap-south-1:463113000000:orders",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "463113000000"
}
}
}
]
}
I want to send notification from SNS (Account A) to Lambda (Account B). Followed this tutorial but still getting below error:
https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html
Error code: AccessDeniedException - Error message: User: arn:aws:sts::AccountA:assumed-role/AdministratorAccessRole/A12345 is not authorized to perform: lambda:AddPermission on resource: arn:aws:lambda:us-east-1:AccountB:function:TestLambda
Below what I did:
1. In Account A, added below policy in Access Policy of SNS:
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "_abc_",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountB:root"
},
"Action": [
"SNS:Subscribe",
"SNS:Receive"
],
"Resource": "arn:aws:sns:us-east-1:AccountA:TriggerLambdaB-SNS"
}
]
}
2. In Account B, added below policy in Resource-Based Policy of Lambda:
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "_abc_",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:AccountB:function:TestLambda",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:sns:us-east-1:AccountA:TriggerLambdaB-SNS"
}
}
}
]
}
I am able to see the SNS Name under Trigger Lambda section of my Lambda in Account B. But when I am trying to Subscribe the Lambda under SNS, then getting this error. Please guide what am I missing here.
Is it because I am having different types of Role in these accounts like AdminAccessRole in Account A and FederatedRoleAccess in Account B?
You need to run the aws sns subscribe in Account-B (with the Lambda function), not Account-A (with the SNS function).
Otherwise, your setup seems correct.
When I tried running the subscribe command from Account-A, it said:
An error occurred (AuthorizationError) when calling the Subscribe operation: The account ACCOUNT-A is not the owner of the lambda function arn:aws:lambda:ap-southeast-2:ACCOUNT-B:function:foo
While this error is different to yours, your command appears to have been run from Account-A (with SNS) rather than Account-B (with Lambda).
Side-note: There appears to be a small error in the Tutorial: Using AWS Lambda with Amazon Simple Notification Service documentation, where the Resource-Based policy for Lambda (the second one in your Question) is showing a SourceArn that refers to Account-B-Lambda, whereas it should be Account-A-SNS. However, you appear to have gotten this correct in your policy above.