Tighten Up Lambda Execution Role Policy By Using Policy Variable (identity ID or Subscriber ID) Fine-Grained Access to DynamoDB

[mingqin1]

Hi:
In current implementation, the lambda execution role policy is coarse-grained, the lambda execution policy should use cognito variable through policy variable to provide fine-grained access control to Amazon DynamoDB resource- just grant access to items in DynamoDB by identity ID or Subscriber ID.

For Example,
lambda function -spacefinder-api-development-bookings-Delete is attached with an execution role policy as

{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"dynamodb:",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "",
"Effect": "Allow"
}
]
}

This policy is allowing lambda function to perform CRUD operations on any items in any DynamoDB tables.

It might be wise to turn above role execution policy into Fine-Grained access control to grant access to items in spacefinder-api-development-bookings by cognito identity ID. See following new policy.
_{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem"
],
"Resource": [
"arn:aws:dynamodb:us-east-1:123456789012:table/spacefinder-api-development-bookings"
],
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
}
}
}
]
}_

How to implement booking.js’s Delete function so it can pass cognito identity id to Fine-Grained policy which grants lambda access to items in spacefinder-api-development-bookings table based on cognito identity ID?

Following is current implementation in api/lambda/booking.js
function Delete(event){
return BookingsTable.delete(
event.pathParameters.bookingId
)
}

event contains user1’s cognito identity id ( assuming user spoofing is prevented),

[dpiechota]

Path DELETE /user/{userId}/booking{bookingId} is not secure. Knowing bookingId I can delete any booking in the database. Would be great to have example how to implement Fine-Grained Access Control for Amazon DynamoDB and Api Gateway. With current design one possible solution is to use:
'ConditionExpression': "userId = :userId", 'ExpressionAttributeValues': { ":userId": {'S': event['requestContext']['identity']['cognitoIdentityId']} }
on the Lambda calling delete in DynamoDB.
For using "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"] this would require key change in DynamoDB bookings table to userCognitoID, as now key is bookingId, therefore "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"] cannot be used

[Gnana143]

@Mozowski I have designed the dynamoDB table with the identityID (userCognitoID) as the leading key but still not able to use the condition of ${cognito-identity.amazonaws.com:sub} in the IAM role. Is there i need to do something more to activate the policy?

[Gnana143]

@mingqin1 we are also using the same implementation as you commented. Did you get any way to resolve from the IAM policies?

[dpiechota]

@Gnana143 I think you need to set the switch in Lambda API Gateway Integration to Invoke with client credentials to allow this as you need but I have not tested this.

[agathao]

Were you able to get this working?