I want to restrict my sqs to accept only from event-bridge rule, below IAM rule looks correct with deny in place, but sqs not receiving message with this, any input appreciated.
{ "Id": "Policy", "Version": "2012-10-17", "Statement": [
{
"Sid": "sid",
"Action": [
"sqs:SendMessage"
],
"Effect": "Deny",
"Resource": "arn:aws:sqs:us-east-1:***:sri-test-queue-3",
"Condition": {
"ArnNotEquals": {
"aws:SourceArn": "arn:aws:events:us-east-1:***:rule/sri-test-bus/sri-test-sqs-rule"
}
},
"Principal": "*"
} ] }
The one generated by Event-bridge to allow sqs access looks like this
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "AWSEvents_sri-test-sqs-rule_Id12",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:***:sri-test-queue-3",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:events:us-east-1:***:rule/sri-test-bus/sri-test-sqs-rule"
}
}
}
]
}
Use the bottom policy. SQS policy denies by default, so you do not need to worry about other resources posting messages to SQS. The policy would allow only arn:aws:events:us-east-1:***:rule/sri-test-bus/sri-test-sqs-rule to send the messages.
The problem with the policy statement you wrote was that you did not have an "Allow" statement, so SQS is denying SendMessage actions from every source.
We just had to put some combination of principalTypes to achieve this, below one worked finally
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ownerstatement",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:xxxx:sri-test-queue-3"
},
{
"Sid": "DenyAllExceptBus",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:xxxx:sri-test-queue-3",
"Condition": {
"ArnNotEquals": {
"aws:SourceArn": [
"arn:aws:events:us-east-1:xxxx:rule/sri-test-bus/sri-test-sqs-rule"
]
}
}
}
]
}
Related
I am struggling with the setting up an S3 policy to give access to Application Load Balancer to push logs.
{
"Id": "Policy1629585161607",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1629585158642",
"Action": "s3:*",
"Effect": "Allow",
"Resource": "arn:aws:s3:::S3bucketname/*",
"Principal": {
"AWS":"arn:aws:iam:LoadBalancerId:root"
}
}
]
}
The LoadBalancerIdcame from the last part of the loan balancer's ARN; follows the trailing slash after the load balancer's name in the ARN.
The error got from S3 is Invalid principal in policy, what have I done wrong?
The AWS docs explain well what the policy should be exactly. Sadly, your policy is incorrect. It should follow the following format:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::elb-account-id:root"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
},
{
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::bucket-name"
}
]
}
On top of that, bucket must be in same region and be encrypted.
I've been through the AWS SNS/SQS subscription instructions multiple times, and have gone through a few different blogs and StackOverflow posts trying various things. However, no matter how many times I try to publish a message to SNS and poll/receive it from SQS, it never pops out the other side. I'm hoping it's something super obvious that I'm missing, that someone with more experience/fresher eyes than me can see.
For some background, I created both SQS and SNS in the same account. I create the subscription last after I have set the access policies for both of them. And I make sure that when I do create the subscription that I get the little green checkmark that says the subscription has been confirmed. Nothing fancy, no FIFO queue, I've set the visibility timeout to 1 minute, and receive message wait time relatively low for the queue as well. I only have in the account one SQS and one SNS, so it's not like I can mess up subscribing or giving access to the wrong ones.
For my SQS access policy this is what it looks like:
{
"Version": "2012-10-17",
"Id": "allow_sns_access_policy",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:<my_unique_id>:<name_of_my_queue>",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-east-1:<my_unique_id>:<name_of_my_topic>"
}
}
}
]
}
My SNS access policy is as follows:
{
"Version": "2012-10-17",
"Id": "allow_sqs_access_policy",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "sqs.amazonaws.com"
},
"Action": "sns:Subscribe",
"Resource": "arn:aws:sqs:us-east-1:<my_unique_id>:<name_of_my_topic>",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-east-1:<my_unique_id>:<name_of_my_queue>"
}
}
}
]
}
I make sure to copy and paste arn resources to limit spelling mistakes. I've experimented with other things, but all of them also didn't work. This to me should work but doesn't.
I guess the policies can be finicky sometimes. I attempted to remove the policies, but that didn't work even though they're in the same region. So here is what I wound up setting for the two policies to get them to correctly communicate. Maybe someone has suggestions for how to make this better, but as of right now this is what works.
SNS policy:
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"Service": "sqs.amazonaws.com"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish",
"SNS:Receive"
],
"Resource": "arn:aws:sns:<region>:<topic_owner>:<topic>",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "<topic_owner>"
}
}
},
{
"Sid": "s3-publish",
"Effect": "Allow",
"Principal": "*",
"Action": "sns:Publish",
"Resource": "arn:aws:sns:<region>:<topic_owner>:<topic>",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "<topic_owner>"
},
"ArnLike": {
"AWS:SourceArn": "arn:aws:s3:*:*:*"
}
}
}
]
}
SQS Policy
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__owner_statement",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<topic_owner>:root"
},
"Action": "SQS:*",
"Resource": "arn:aws:sqs:<region>:<topic_owner>:<queue_name>"
},
{
"Sid": "topic-subscription-arn:aws:sns:<region>:<topic_owner>:<topic_name>",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:<region>:<topic_owner>:<queue_name>",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:sns:<region>:<topic_owner>:<topic_name>"
}
}
}
]
}
I wanted to allow all s3 actions on a particular bucket "test-bucket" for a specific role "test-role". Deny the bucket for all others. The s3 policy I have written :
{
"Version": "2012-10-17",
"Id": "Policy1601973417173",
"Statement": [
{
"Sid": "Allow role test-role",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxx:role/test-role"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::test-bucket/*"
},
{
"Sid": "Deny rest",
"Effect": "Deny",
"NotPrincipal": {
"AWS": "arn:aws:iam::xxxxxxxx:role/test-role"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::test-bucket/*"
}
]
}
Even after applying the above policy, the sso users which are mapped to the role "test-role" is getting Access denied on the bucket.
Note : The AWS console shows logged in user as "Federated Login: test-role/sam#abc.com".
I have also tried the "assumed-role" options are still failing. Any help appreciated.
Try this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test-bucket",
"arn:aws:s3:::test-bucket/*"
],
"Condition": {
"StringNotLike": {
"aws:userId": [
"AIDA<udserid-1-suppressed>:*",
"AIDA<udserid-1-suppressed>",
"AIDA<udserid-2-suppressed>:*",
"AIDA<udserid-2-suppressed>",
"AIDA<udserid-n-suppressed>:*",
"AIDA<udserid-n-suppressed>",
"111111111111"
]
}
}
}
]
}
I have a codepipeline on Account A and codedeployment group on Account B. I'm seeing the below error once the codedeployment group start the trigger
The IAM role arn:aws:iam::accountb:role/testcrss does not give you permission to perform operations in the following AWS service: Amazon S3. Contact your AWS administrator if you need help. If you are an AWS administrator, you can grant permissions to your users or groups by creating IAM policies.
I was referring to this document provided by aws for aws cross-account deployment using codepipeline, do I need to configure anything other than the info provided in the document?
policies attached to testcrss role
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:Get*",
"s3:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey*",
"kms:Encrypt",
"kms:ReEncrypt*",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-2:AccountA:key/valuetest"
]
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::AccountA bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::AccountA bucket"
]
}
]
}
Bucket policy on Account A
{
"Version": "2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::AccountAbucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::AccountAbucket/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountB:root"
},
"Action": [
"s3:Get*",
"s3:Put*"
],
"Resource": "arn:aws:s3:::AccountAbucket/*"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountB:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::AccountAbucket"
},
{
"Sid": "Cross-account permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountB:role/testcrss"
},
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "arn:aws:s3:::AccountAbucket/*"
}
]
}
Trust Relationship for Role testcrss
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"codedeploy.amazonaws.com",
"ec2.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
The issue was the KMS key which was added to Account B was incorrect, this key is required to access the s3 bucket on Account A.
KMS key should be the same as the KMS key attached to the codepipeline on Account A
I’ve created a set of AWS Lambdas using the Serverless framework, and a React app which calls these. A user pool and an identity pool have been setup in AWS Cognito, and a table in DynamoDB. (I've followed the tutorial on serverless-stack.com). It's a simple notes app.
The client app is deployed to: https://dev.cakebook.co
The API is deployed: https://api.cakebook.co/dev/orders
However, after I log in using this Cognito user:
admin#example.com
Passw0rd!
I get a 403 response for the GET of the orders:
message: “User: arn:aws:sts::********8766:assumed-role/cakebook-api-dev-CognitoAuthRole-1DTRT5XGEGRXW/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-east-2:********8766:sss6l7svxc/dev/GET/orders”
I'm new to all this, but it looks like my Cognito user does not have permission to call the Lambda (or API gateway?). Is that the issue? If so, how do I give the users permission to call the Lambdas?
UPDATE, requested JSON
Execution Role:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogStream"
],
"Resource": [
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-create:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-get:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-list:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-update:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-delete:*"
],
"Effect": "Allow"
},
{
"Action": [
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-create:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-get:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-list:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-update:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-delete:*:*"
],
"Effect": "Allow"
},
{
"Action": [
"dynamodb:DescribeTable",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem"
],
"Resource": [
"arn:aws:dynamodb:us-east-2:********8766:table/orders"
],
"Effect": "Allow"
},
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:********8766:function:cakebook-api-dev-list",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cognito-identity:us-east-2:********8766:identitypool/us-east-2:d9e4e505-c64a-4836-8e56-3af843dbe453"
}
}
}
]
}
Function Policy:
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "cakebook-api-dev-ListLambdaPermissionApiGateway-U7OCBI3JM44G",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:********8766:function:cakebook-api-dev-list",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:execute-api:us-east-2:********8766:w5o4vxx4f0/*/*"
}
}
},
{
"Sid": "lambda-da48f6d0-6d3c-4bbf-a761-ca3510f79624",
"Effect": "Allow",
"Principal": {
"Service": "cognito-sync.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:********8766:function:cakebook-api-dev-list",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cognito-identity:us-east-2:********8766:identitypool/us-east-2:d9e4e505-c64a-4836-8e56-3af843dbe453"
}
}
}
]
}
You need to update Lambda permission to allow invoking by Cognito user pool.
Option A - update permission in JSON format
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "lambda-something",
"Effect": "Allow",
"Principal": {
"Service": "cognito-sync.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:eu-west-1:__accountId__:__function_name__",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cognito-identity:eu-west-1:__accountId__:identitypool/eu-west-1:....."
}
}
}
]
}
Option B - in console
Go to Lambda Configuration page
Add trigger Cognito Sync Trigger
During saving it will offer to configure Lambda permission automatically - agree