The short answer is no, this is not currently possible, but a multi-account strategy might provide a different way to solve this problem.
Why is this not possible?
For this to work, you would need Lambda to provide a context key to IAM that had the information about which user created the lambda. At the moment Lambda does not provide any context keys.
From Actions, Resources, and Condition Keys for AWS Lambda:
Lambda has no service-specific context keys that can be used in the Condition element of policy statements. For the list of the global context keys that are available to all services, see Available Keys for Conditions in the IAM Policy Reference.
The desire to control permission to a Lambda based on who created it sounds like a problem where you need to provide administrative isolation between users or teams.
For example if user A (or person from team A) creates a function then they should be able to manage it throughout its life-cycle, but other users (or people from other teams) should not be able to interfere with it.
If this is the type of problem you face then having multiple AWS accounts is probably a good solution for you.
Organizations provides policy based management for multiple accounts. A common scenario would be to have:
- A bill paying account
- An identity account (contains all the user logins)
- Resource accounts (contains the AWS resources, and cross-account roles to allow users from the identity account to have the appropriate level of access to the resources)
You'd create resource accounts to provide the administrative isolation, so user A would have their own account and could do whatever you let them, without having to worry about interferring with user B. Equally teams could be given access to an account.
This also provides the benefit providing a billing break down per account and limiting the blast radius of any security incident to the account it occurred in.