Configuring Lambda execution role permissions - Amazon Lambda
Basic permissionsCluster access permissionsVPC permissionsOptional permissions
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Configuring Lambda execution role permissions

To access the Amazon MSK cluster, your function and event source mapping need permissions to perform various Amazon MSK API actions. Add these permissions to the function's execution role. If your users need access, add the required permissions to the identity policy for the user or role.

To cover all required permissions, you can attach the AWSLambdaMSKExecutionRole managed policy to your execution role. Alternatively, you can add each permission manually.

Basic permissions

Your Lambda function execution role must have the following required permissions to create and store logs in CloudWatch Logs.

Cluster access permissions

For Lambda to access your Amazon MSK cluster on your behalf, your Lambda function must have the following permissions in its execution role:

You only need to add one of either kafka:DescribeCluster or kafka:DescribeClusterV2. For provisioned Amazon MSK clusters, either permission works. For serverless Amazon MSK clusters, you must use kafka:DescribeClusterV2.

Note

Lambda eventually plans to remove the kafka:DescribeCluster permission from the AWSLambdaMSKExecutionRole managed policy. If you use this policy, migrate any applications using kafka:DescribeCluster to use kafka:DescribeClusterV2 instead.

VPC permissions

If your Amazon MSK cluster is in a private subnet of your VPC, your Lambda function must have additional permissions to access your Amazon VPC resources. These include your VPC, subnets, security groups, and network interfaces. Your function's execution role must have the following permissions:

Optional permissions

Your Lambda function might also need permissions to:

  • Access your SCRAM secret, if you're using SASL/SCRAM authentication. This lets your function use a username and password to connect to Kafka.

  • Describe your Secrets Manager secret, if you're using SASL/SCRAM or mTLS authentication. This allows your function to retrieve the credentials or certificates needed for secure connections.

  • Access your Amazon KMS customer-managed key, if you want to encrypt your filter criteria. This helps keep your message filtering rules secret.

  • Access your schema registry secrets, if you're using a schema registry with authentication:

    • For Amazon Glue Schema Registry: Your function needs glue:GetRegistry and glue:GetSchemaVersion permissions. These allow your function to look up and use the message format rules stored in Amazon Glue.

    • For Confluent Schema Registry with BASIC_AUTH or CLIENT_CERTIFICATE_TLS_AUTH: Your function needs secretsmanager:GetSecretValue permission for the secret containing the authentication credentials. This lets your function retrieve the username/password or certificates needed to access the Confluent Schema Registry.

    • For private CA certificates: Your function needs secretsmanager:GetSecretValue permission for the secret containing the certificate. This allows your function to verify the identity of schema registries that use custom certificates.

These correspond to the following required permissions:

Additionally, if you want to send records of failed invocations to an on-failure destination, you'll need the following permissions depending on the destination type:

  • For Amazon SQS destinations: sqs:SendMessage - Allows sending messages to an Amazon SQS queue

  • For Amazon SNS destinations: sns:Publish - Permits publishing messages to an Amazon SNS topic

  • For Amazon S3 bucket destinations: s3:PutObject and s3:ListBucket - Enables writing and listing objects in an Amazon S3 bucket

For troubleshooting authentication and authorization errors, see Troubleshooting Kafka event source mapping errors.