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?