Lambda Roles and SCPs - amazon-web-services

have a question regarding Lambda and Roles and SCPs.
Lets say that I have a Lambda function doing a certain IAM call, the lambda role has the permission needed for doing it.
The Lambda it self is created with a Cloudformation. The Cloudfromation deployment is ran with a tool using the service role for the tool, no service role for the CF.
The Lambda Function is triggered by a Custom Resource in the same CF.
Tool(with role) -> CF(No service role) -> CR -> Lambda -> IAM call
Now add a SCP with a Deny for the IAM call. What principal needs to have condition in the SCP to not be affected by the SCP?

The role you use for the lambda is the principal that needs an exception in the SCP. Ultimately, it is the principal that is running the lambda that is making the IAM call, so that is what will need the condition.

Related

AWS Lambda doesn't have DynamoDB permissions when invoked by URL/API Gateway

We have a pair of existing AWS Lambda functions that read/write from a DynamoDB table. I created a new function and table; the function is very basic, just does a putItem on the DynamoDB table. I can successfully invoke it with the test functionality in Lambda.
However, if I invoke the Lambda function using the FunctionURL or via API Gateway, I get the following error.
Yet in Configuration > Permissions in the Lambda interface I clearly see the permission:
Suggestions where to check next? Comparison to our existing, working functions hasn't revealed anything; everything I have checked in configured the same.
Thanks!
When you invoke the lambda function in the lambda console, lambda is using an Execution role.
When you invoke the lambda function via API gateway or via the function URL, it is likely that you are using IAM authorization. As a result, lambda is using the role of the principal who invoked the function (in this case, PatientWellnessDeregistration-role-3ospc0u3).
The execution role is configured correctly, but the IAM role of the principal is lacking the required permissions.
Further reading:
https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html
https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html
What you could optionally check is that API Gateway is authorized to call your new Lambda. If so, then the Resource-based policy of the Lambda (still in the Permissions tab) should have something similar to:
Resource-based policy example:

What is the purpose of having an option for both role and resource-based policy in Lambda when role inherently has 1 or more policies?

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.

Where in the IAM can I see the policy configured using aws lambda add-permission?

This AWS CLI command:
aws lambda add-permission --function-name my_test_Lambda_fn --statement-id test_id --principal iotanalytics.amazonaws.com --action lambda:InvokeFunction
Gives the following output:
{
"Statement": "{\"Sid\":\"test_id \",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"iotanalytics.amazonaws.com\"}...
}
I wanted to see the above in IAM console, so I tried looking at the roles used by IoTAnalytics and Lambda; and in their respective policies; but the above output is not part of any policy. Where in the IAM can I see the policy configured by the above AWS CLI command? I think that it configured at principal level, but where do I see it in the IAM console?
This isn't actually an IAM policy (although it might resemble one). In fact it is a type of resource policy (in this case named Function policy).
Certain services such as S3, SNS, SQS and in this case Lambda have the ability to have a policy attached which dictates how other entities can interact with them such as other AWS accounts or services that do not support an attached IAM role.
From within the console on the Lambda function itself access the Permissions tab, then at the bottom of the page is a sub-item named Resource-based policy. This will contain the policy that you have added.
You have to go into the Lambda console, select your Function and then you can click on Permissions to see the permissions attached to your lambda.
These are resource-based permission for the lambda function. You can view them in AWS console -> Permissions -> Resource-based policy:

How to see which lambda execution role is used to execute a lambda function & Diff between AssumeRole vs LambdaExecution Role

1, How can I see 'which role' is being used to execute a lambda function? I have logged event in Cloudwatch but there is nothing regarding IAM role or AssumeRole.
2, Is AssumeRole is much different from a lambda execution role? Right now in my lambda, I have a function with an authorizer. The authorizer will check the token of the user and in the call back it will pass generated policy.
So what I have understood is,
First, we call the "Function" and Automatically it will trigger authorizer. The authorizer will pass an IAM role to the "Function" then it will execute it. So my question is, is this AssumeRole is a lambda:Execute role?
So what's the difference between the Default lambda execution role and this AssumeRole?
You can use AWS CloudTrail for this. See https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html
Assumed role is the role the request acts upon. The concept of role is the most core in the AWS, to perform an action (like an API call) you have to have a role.
The authorizer uses AssumeRole to assume a role to the client. AssumeRole generates temporal IAM credential an entity can access AWS resources with. On the other hand, an execution role is the role a resource (like AWS Lambda) acts upon. For example, if your Lambda reads from a DynamoDB table, its execution role must include a permission dynamodb:GetItem - this doesn't have to be included in the assumed role.

Use AWS Lambda to access S3 using only Roles

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