aws-lambda: `addPermission` doesn't allow overriding auto-generated statement ID
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
## Description
When using `addPermission` method on a Lambda function, CDK generates a resource-based policy statement with an auto-generated statement ID that begins with the construct path. There is currently no way to override this behavior and specify a custom statement ID that will be used in the actual AWS resource.
## Current Behavior
When calling `addPermission` with a statement ID like:
```typescript
myFunction.addPermission("AllowCWL", {
principal: new ServicePrincipal("logs.amazonaws.com"),
action: "lambda:InvokeFunction",
sourceArn: `arn:aws:logs:${this.region}:${this.account}:log-group:*`,
sourceAccount: this.account,
});
```
The statement ID in the actual Lambda resource-based policy becomes something like:
`-`
As seen in the AWS Console:

## Expected Behavior
The `addPermission` method should have an optional property to specify the exact statement ID to use in the deployed resource-based policy. For example:
```typescript
myFunction.addPermission("AllowCWL", {
principal: new ServicePrincipal("logs.amazonaws.com"),
action: "lambda:InvokeFunction",
sourceArn: `arn:aws:logs:${this.region}:${this.account}:log-group:*`,
sourceAccount: this.account,
statementId: "AllowCWL" // <-- Proposed property to override the auto-generated ID
});
```
## Additional Information
The AWS Lambda API itself allows specifying the statement ID directly when adding permissions. This feature request is to expose this capability through the CDK API.
### AWS Lambda API vs. CDK Implementation
#### Lambda API Behavior
- The native AddPermission API **requires** a user-specified StatementId parameter
- This ID must be unique within the function's policy
- Manual AWS CLI command example:
```bash
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id AllowCWL \
--principal logs.amazonaws.com \
--source-arn arn:aws:logs:us-west-2:123456789012:log-group:* \
--source-account 123456789012
```
#### CDK Current Implementation
- CDK auto-generates statement IDs using construct paths and logical IDs
- Generated IDs follow pattern: `-`
- No exposed `statementId` property in Permission interface:
```typescript
// Current CDK interface (simplified)
interface Permission {
principal: IPrincipal;
action?: string;
sourceArn?: string;
// Missing statementId property
}
// Proposed solution would require
interface Permission {
// ...existing properties
statementId?: string; // New optional property
}
```
#### Current Workaround (Complex and Fragile)
```typescript
// Using escape hatch to modify generated policy
const cfnFunc = myFunction.node.defaultChild as lambda.CfnFunction;
cfnFunc.addOverride('Properties.Policy.Statement.0.Sid', 'CustomID');
```
### CDK CLI Version
2.190.0
### Framework Version
_No response_
### Node.js Version
22.14.0
### OS
Ubuntu 24.04
### Language
TypeScript
### Language Version
_No response_
### Other information
_No response_
Contributor guide
Research direction
Locate the Lambda Function addPermission entry point and the Permission interface, then trace how the policy statement ID is generated. Add the optional statementId behavior described in the issue and verify that synthesis or deployment uses the supplied ID while preserving current behavior when it is omitted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- backend-api-design, cloud
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100