I have a queue with has policy that allows sendMessage, receiveMessage actions via a service role (Principal has role arn). Lambda and other services use this role to send messages to this queue.
I also have a AWS console developer role that allows me to send a message via console (SQS send, receive message option).
If SQS policy explicitly allows sendMessage only for a service role, how am I able to post via AWS console?
From Using identity-based policies with Amazon SQS - Amazon Simple Queue Service:
Using Amazon SQS and IAM policies
There are two ways to give your users permissions to your Amazon SQS resources: using the Amazon SQS policy system and using the IAM policy system. You can use one or the other, or both. For the most part, you can achieve the same result with either one.
There is one major difference between IAM and Amazon SQS policies: the Amazon SQS policy system lets you grant permission to other AWS Accounts, whereas IAM doesn't.
Basically, you can use either an SQS Policy or an IAM Policy. If one of them permits the action, with neither of them Denying the action, then the action will be permitted.
When you are using the Amazon SQS console, you are most probably using an IAM permission that has been assigned to you. If it grants the necessary permission, then the SQS Policy is not required.
Related
I am trying to set cross account data transfer from AWS Lambda in AWS account A to SQS in AWS account B using boto3. Below are the steps which I have followed.
Created an IAM role in account A which has "SendMessage" access to SQS queue in account B. (Given an ARN of SQS queue of account B)
Added an account ID of AWS account B in the trust relationship of an IAM role in account A.
Attached this IAM role to Lambda function and written a code to send the message to SQS queue using SQS queue URL.
Created an SQS queue in account B.
In the SQS queue access policy I have written a policy which will allow lambda role of account A to send message to its SQS queue.
================================================================================
After that when I am trying to test my lambda function, it is giving me below error.
[ERROR] ClientError: An error occurred (AccessDenied) when calling the SendMessage operation: Access to the resource https://queue.amazonaws.com/ is denied.
=====================================================================================
Can anybody please help to understand what's wrong here?.
This error can occur if you are attempting to access SQS via the boto3 Python library (e.g. OP's lambda) from inside a VPC with private DNS enabled.
Per AWS documentation:
Private DNS doesn't support legacy endpoints such as queue.amazonaws.com or us-east-2.queue.amazonaws.com.
(emphasis mine)
To solve this error:
Create a VPC endpoint for com.amazonaws.<region>.sqs in your VPC
Pass the appropriate service endpoint URL to the boto3.client() constructor:
import boto3
client = boto3.client('sqs', endpoint_url='https://sqs.%s.amazonaws.com' % region)
IAM permissions are left as an exercise to the reader.
I have created a Lambda function. In the permissions pane there is section for role and another section for resource-based policy.
A role in IAM inherently has a policy. This specifies the resources and actions that the function (via role) has permission to access.
So what is the purpose of having the section for Resource-based policy? If there is access allowed in one and denied in another than which permission is prioritized.
They are two different things.
The role is what the lambda can do (i.e. what the function itself has access to when executing)
The resource-based policy is what other principals can do to the Lambda (i.e. who can execute it, who can update it, who can see it, who can delete it etc)
Lambda is one of a number of services in AWS where this dual set of policies is required as it is both a resource that can be acted upon, and runs as a principal which can act on other things. EC2 Instance Roles are another example.
The IAM role that is attached to the Lambda is used to grant the Lambda the ability to communicate with other AWS resources other the API. If the IAM policy allows access to perform an action, as long as there are no Deny statements the action should be able to be carried out.
The function policy on the other hand is a policy that evaluates invocation of your Lambda function, by default resources within your AWS account can invoke the Lambda should they have the right IAM permissions.
Some services do not have an IAM role that are assigned to them however, so properties such as the Arn of the calling resource or the service that is attempting to invoke the Lambda. In addition you can grant access to another AWS account, or restrict which IAM principals should be able to invoke the function. This is similar to the property of a bucket policy in an S3 bucket.
As per the AWS documentation here.
Identity-based policies are attached to an IAM user, group, or role. These policies let you specify what that identity can do (its permissions). For example, you can attach the policy to the IAM user named John, stating that he is allowed to perform the Amazon EC2 RunInstances action. The policy could further state that John is allowed to get items from an Amazon DynamoDB table named MyCompany. You can also allow John to manage his own IAM security credentials. Identity-based policies can be managed or inline.
Resource-based policies are attached to a resource. For example, you can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, and AWS Key Management Service encryption keys. For a list of services that support resource-based policies, see AWS services that work with IAM.
With resource-based policies, you can specify who has access to the resource and what actions they can perform on it. To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see What is IAM Access Analyzer?. Resource-based policies are inline only, not managed.
I have a Lambda function written in Java I and I want it to access S3 (putObject).
I do not want to use or store credentials in my Lambda function in order to access S3. Instead, I would like to use IAM roles.
How can I code an AWS S3 client inside my java code (that would be ran by Lambda) that won't need any credentials and assume that the Lambda has the appropriate Role?
You don't need to store credentials in your lambda functions. All funtions run with a role - the role you set when you created the function. Since the lambda function has a role, you can add or remove permissions from this role as needed, without changing the function itself
Manage Permissions: Using an IAM Role (Execution Role)
Each Lambda function has an IAM role (execution role) associated with
it. You specify the IAM role when you create your Lambda function.
Permissions you grant to this role determine what AWS Lambda can do
when it assumes the role. There are two types of permissions that you
grant to the IAM role:
If your Lambda function code accesses other AWS resources, such as to
read an object from an S3 bucket or write logs to CloudWatch Logs, you
need to grant permissions for relevant Amazon S3 and CloudWatch
actions to the role. If the event source is stream-based (Amazon
Kinesis Streams and DynamoDB streams), AWS Lambda polls these streams
on your behalf. AWS Lambda needs permissions to poll the stream and
read new records on the stream so you need to grant the relevant
permissions to this role.
http://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html
I am deploying an EC2 instance using CloudFormation and I need to publish information about the created instance to an HTTP endpoint. I plan on doing this using SNS. However, I do not want the instance to have permanent access to publish to the endpoint or be able to use the AWS CLI.
Is there a way to deploy the instance with permission to publish to a specified SNS topic and then rescind permission immediately afterwards?
Use IAM (IAM and Amazon SNS Policies Together) to create a SNS Role which has just enough privileges to publish a specified SNS topic.
Launch the instance and specify the your role as instance's IAM profile
After publishing, remove the SNS privileges from the role using the IAM dashboard or from the instance (make sure the role has privileges to rescind the permission)
I am currently trying to enable AWS Config notifications on multiple accounts. I have enabled monitoring on each individual account with its own S3 bucket and SNS topic, but it would make more sense to have one centralized bucket and topic. I am trying to implement this with little success.
I have created an s3 bucket and target ARN but when I try and apply the changes I get an error of insufficient delivery policy
Note I am doing this through the AWS console and not with code.
To do this, you need two pieces:
The Identity and Access Management (IAM) Role being used must have permissions to deliver data to the common S3 bucket and SNS Topic. You'll need to go to the IAM Management Console, and edit the role being used by Config in each account and update the S3 bucket/SNS names in "PutObject", "GetBucketACL" and "sns:Publish"
You also need to allow the S3 bucket and SNS Topic to receive data from this new role. See
a. http://docs.aws.amazon.com/awscloudtrail/latest/userguide/aggregating_logs_accounts_bucket_policy.html
b. http://docs.aws.amazon.com/sns/latest/dg/AccessPolicyLanguage_UseCases_Sns.html