I have registered a free tier AWS Lambda account and created a simple, public service for me and others to play around with. However, since I do not know yet how usage is going to be, I want to be careful for now. Otherwise someone could simply flood my service with one million requests and I get billed for it. I'd rather not have the service available.
Therefore, I want to create a budget action that shuts down all services as soon as $0.01 is exceeded. The way I've done this is that I've granted the Lambda service role (which was auto-created when I setup the lambda service) the budget permission (budgets.amazonaws.com) and then have an IAM action setup that adds the AWSDenyAll managed policy to the role itself once the budget is exceeded.
This does not seem to work. If I manually attach the AWSDenyAll policy, the Lambda service still is available. My understanding of the roles/policies system may be also fundamentally wrong.
How can I achieve a "total shutdown" action that can be triggered from a budget alert?
You're applying the AWSDenyAll policy to the execution role of the Lambda function, which is used to define permissions to access AWS resources from the Lambda itself (Configuration > Permissions > Execution role).
You essentially have blocked the Lambda function itself from accessing AWS services.
You haven't blocked any IAM principals (users or roles), AWS services (including API Gateway) or other AWS accounts which is why your Lambda can still be invoked manually or via the gateway.
Now, a question that may now arise is "how can I prevent the API Gateway from invoking my Lambda?".
The way that API Gateway is given access to trigger your Lambda is via resource-based permissions policies (Configuration > Permissions > Resource-based policy).
This is not "encapsulated" within an IAM entity (user or role) and currently, you can only update resource-based policies for Lambda resources within the scope of the AddPermission and AddLayerVersionPermission API actions.
This means that the only way to revoke API Gateway's access to invoking your function would be to delete the resource policy allowing API Gateway to invoke your function using the RemovePermission API action or via the console.
There would be no way to do this via budget actions.
The other question that can arise is "how can I prevent API Gateway and the Lambda function from being invoked then?".
This still wouldn't be possible using Budget Actions as per docs, you can only apply an IAM policy or a service control policy (SCP) none of which will help you to prevent triggering of a Lambda which is triggered via the API Gateway. You can prevent the Lambda from being triggered by AWS users within the console but you can't prevent the API Gateway unless you are using IAM to authenticate your users.
There isn't any way to "shutdown" Lambda functions or the API Gateway once you hit a specific budget limit.
You will just have to create a budget to alert you, filter on the service dimension to the Lambda and API Gateway services for example, and then take manual action (setting a monthly usage budget with a fixed usage amount and actual/forecasted notifications).
Related
We have an AWS account with an IAM group, this group contains practically 6 users and most operations in the account are done by this 6 users.
There are 12 Lambda Functions that have been created in the account and there is a particular lambda function (created by one of the 6 users) that I am trying to know who created it (The Lambda function owner).
Please is there a way to do this ?
Resources created in AWS Accounts are associated with the Account, not the IAM User that created the account.
When a user requests AWS to create resources, IAM verifies that the user has permission to create resources. If so, then the resources are created in the Account, but no relationship with the user is kept on that resource.
You can, however, use AWS CloudTrail to view information about the API request that created the resource.
From What Is AWS CloudTrail? - AWS CloudTrail:
AWS CloudTrail is an AWS service that helps you enable governance, compliance, and operational and risk auditing of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. Events include actions taken in the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs.
I'm struggling to understand the practical differences between an execution role that can be assumed by API gateway to grant the permission to execute a lambda over a lambda resource-based policy.
For example, the documentation here provides an example of a policy that can be assumed by the API gateway to invoke a Lambda.
However, the API Gateway console will grant itself permission to access a Lambda via a lambda resource-based policy.
Both achieve the desired outcome of allowing the API Gateway to execute a Lambda. So is there a reason to choose one over the other?
Apart from the general use case / advantages of having resource-based policy that is explained pretty well here
does not have to give up his or her permissions to receive the role permissions
In this specific case, I have experienced 2 distintive advantages using Lambda's resource based policy over role
The creator of Lambda - API Gateway integration does not need to have access to IAM. No role created
Because no role is created, no role need to be cleaned up. The developer delete the Lambda function he created to play around and everyone can forget about it
I think one of the significant advantages of resource-based policies is that they can be applied to specific versions or aliases. This is unlike IAM roles, which cannot target a specific version or alias.
Im creating a lambda function to tag resources with a specific tag depending on the role that creates the resource:
if role = dev:
then
ec2.create_tags(Resources=instance_ids,Tags=[{'Key':'environnement','Value':'dev'}])
elif role = prod:
ec2.create_tags(Resources=instance_ids,Tags=[{'Key':'environnement','Value':'prod'}])
.....
My question:
How can I get information about the role that creates the resource?
Thanks in advance !!
AWS resources do not store "who" created the resource.
When an API call is sent to AWS to create a resource, AWS will check whether the provided credentials are permitted to create the resource (eg an Amazon EC2 instance). If they are permitted, then the resource is created and the resource is associated with an AWS account. No indication of who made the API request is stored on the resource.
However, you can use AWS CloudTrail to view an audit log of API calls, including the identity that made the API call. This identity might be associated with an IAM User or an IAM Role, or even the root credentials of the AWS account.
From Using AWS Lambda with Amazon CloudWatch Events - AWS Lambda:
Amazon CloudWatch events help you to respond to state changes in your AWS resources. When your resources change state, they automatically send events into an event stream. You can create rules that match selected events in the stream and route them to your AWS Lambda function to take action.
Thus, you can configure CloudWatch Events to trigger the Lambda function whenever a specific event happens (eg RunInstances). Full details of the event will be passed to the Lambda function, so it can determine who triggered that event.
I have a AWS Lambda function in production. Triggering it can lead to monetary transactions. I want to block the feature of testing this lambda through AWS console so that users having console access cannot accidentally trigger it for the purpose of testing which they can do on the corresponding staging lambda. Is it somehow possible?
First solution that I would recommend is to not mix production and other workloads in the same AWS account. Combine that with not giving your developers and users credentials to the production account.
Assuming that you don't want to do that, you could apply a resource policy on the Lambda function that denies all regular IAM users permission to invoke the Lambda function. Be sure that your policy does not deny the 'real' source in your production system (e.g. API Gateway or SQS or S3). You should also prevent your users from modifying the resource policy on the Lambda function.
Alternatively, if all of your IAM users are managed under IAM groups, then you could apply an additional group policy that denied all actions on the Lambda function ARN. Again, ensure that they cannot modify the group policy to remove this control.
I want to call api gateway from our own backend which is a ECS cluster, and I want to use IAM authorization, is there any way to not manually sign the request using Access Key and Secret Key?
For example when Lambda call KMS to decrypt environment variables, no need to configure the AWS SDK. Wondering if there's similar thing for API gateway.
It is definitely possible, even more - it's a security best practice. You can assign IAM roles to all computing services of AWS: Lambda, EC2, ECS, Beanstalk etc. On ECS you can assign IAM roles to your tasks.
It gives a great benefit, which is well described in official docs:
Benefits of Using IAM Roles for Tasks
Credential Isolation: A container can only retrieve credentials for the IAM role that is defined in the task definition to which it belongs; a container never has access to credentials that are intended for another container that belongs to another task.
Authorization: Unauthorized containers cannot access IAM role credentials defined for other tasks.
Auditability: Access and event logging is available through CloudTrail to ensure retrospective auditing. Task credentials have a context of taskArn that is attached to the session, so CloudTrail logs show which task is using which role.
This link will help you: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html