Lambda permission uses a wildcard principal

Description

Using principal: "*" in a Lambda resource policy can broaden the allowed callers. Effective access depends on the granted action, conditions, invocation path and other permission controls. A wildcard alone does not establish that every request is allowed.

For AWS service integrations, specify the required service principal and restrict the actual event source with supported source_arn and source_account conditions. Restrict accounts or roles making direct calls according to that invocation path.

Potential impact

Unnecessary allowed invocations can increase execution costs and downstream processing load.
Weak input validation or excessive function permissions can enable unintended data processing or changes.

Remediation

Allow only the accounts, roles or services that need to invoke the function, with the required actions.
Apply supported source conditions to service calls and verify that they identify the actual resources and accounts.
Remove unnecessary statements from the existing function policy and test legitimate events and unapproved calls. Adding a new statement alone does not remove existing public permissions.

Examples

These examples grant S3 invocation access to an existing function and its Dev alias. Replace the bucket and owner account with actual values, and configure S3 event notifications separately. To change an existing statement, check the installed module's behavior and remove or replace the old grant.

Before

yaml

- name: Lambda 권한 설정
  community.aws.lambda_policy:
    state: present
    function_name: functionName
    alias: Dev
    statement_id: lambda-s3-myBucket-create-data-log
    action: lambda:InvokeFunction
    principal: "*"
    source_arn: arn:aws:s3:::example-trigger-bucket
    source_account: "123456789012"

The principal is a wildcard, but source ARN and account conditions are present. This does not allow arbitrary requests that fail those conditions.

After