cloud watch event invocation failed to call sns topic - amazon-web-services

I am a beginner to AWS CloudWatch. The event is not getting triggered when I use AWS java SDK to create CloudWatch event rules, and using sns topic as a target.
It's working fine when created using Direct AWS management console.
Everything remains the same when comparing java sdk creation and management console creation.
The only difference is in aws management console rules invoke, two metrics are created(invocation, TriggeredRules), in java sdk rules invoke, three metrics are created(invocation, TriggeredRules,FailedInvocation).

If you use a custom KMS key on your SNS Topic, you need also add the following policy to your KMS key policy:
{
"Sid": "CloudwatchEvents",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": [
"kms:Encrypt*",
"kms:Decrypt*",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:Describe*"
],
"Resource": "*"
}

If you find that it works when created via the console but not if you do it with the API (or something like Terraform) then it is likely that you are not updating the SNS Topic Policy so that it allows events to be published from CloudWatch Events. The console does this for you semi-magically but if you use the APIs you have a bit more work to do.
There is an answer here in the FAQ with the details but the long and short of it is you need to add (not replace) something like this to your SNS Topic Policy:
{
"Sid" : "CloudWatchEvents",
"Effect" : "Allow",
"Resource" : "${aws_sns_topic.events.arn}",
"Action" : "sns:Publish",
"Principal" : {
"Service" : "events.amazonaws.com"
}
}

Related

Why do some AWS services require the requestor to have IAM policies?

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.

AWS default Access Policy SNS topics and SQS q's

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"
}
}
}
]
}

CodeCommit Notification does not send event to SNS

I set up Notification in CodeCommit on all events. The rule target SNS topic has a policy that allows principal *. However when I created a pull request. There is no event went through my SNS topic. I have a email subscription to the topic.
What have I missed and what is the possible causes?
I was having the same problem.
The solution is to give permission in SNS to receive notifications from CodeCommit. To do so you need to edit the SNS "Access policy" and add the following rule:
{
"Sid": "AWSCodeStarNotifications_publish",
"Effect": "Allow",
"Principal": {
"Service": [
"codestar-notifications.amazonaws.com"
]
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:123456789012:codestar-notifications-MyTopicForNotificationRules"
}
Just make sure to edit the Resource property first.
Source, full explanation and example here: https://docs.aws.amazon.com/codestar-notifications/latest/userguide/notification-target-create.html

AWS IoT Rule engine not working

Somehow none of the AWS IoT Rule are working for me.
I published to topic, and sent SNS (as per example).
SELECT * FROM 'acme/temp'
All policy and trust policy are correct , yet it does not fire rule.
Sad part is log level is DEBUG configured yet cloud watch shows only INFO and no info to know why rules not fired.
Trust policy
{
"Version":"2012-10-17",
"Statement":[{
"Effect": "Allow",
"Principal": {
"Service": "iot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}]
Role Policy
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-1:643170122694:snstopic"
}
}
Pl suggest how to troubleshoot.
I am using MQTT client inside AWS console to publish message to topic. If I subscribe then I get messages. I put my rule configuration here forums.aws.amazon.com/thread.jspa?messageID=741034&tstart=0 Can you think of any ways I can troubleshoot .. No matter what rule I write and what action I defined .. it does not fire Iot rule engine. I am using us east 1 region.

Accessing AWS SQS running under different AWS root account

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!