Currently AWS elasticsearch in a VPC configuration will not allow a remote account to post to it while VPC peering unless the lambda assumes a role in the remote account that has permissions to ESHttpPost.
🐞 Problem
A simple way to address this would be to provide a methodology to inject credentials other than the current execution role into the Post call. This requires invoking STS AssumeRole to get new credentials against the targeted role arn and providing those to the Post call. This could be expanded upon to provide alternate posting methodologies to support self hosted elasticsearch but that would also require either a non-aws post function call with the necessary authorization headers/information or rework of the existing post function call to determine which authorization headers/information need to be sent.
🎯 Goal
Good security isolation would indicate to leverage multiple AWS accounts for serverless services. By separating out the accounts, you limit blast radius. However, in doing so you also want to have an account that can handle centralized log aggregation of some kind. Elasticsearch is a good target for that. This change would allow you to use the plugin as is, provide an environment variable for the role arn to assume, and provide for cross-account ESHttpPost calls.
💡 Possible Solutions
#429 is a possible solution. I have tested and used it in the VPC elasticsearch configuration with vpc peering in place and assuming a role in the elasticsearch account which is separate from the serverless deployment account.
Currently AWS elasticsearch in a VPC configuration will not allow a remote account to post to it while VPC peering unless the lambda assumes a role in the remote account that has permissions to ESHttpPost.
🐞 Problem
A simple way to address this would be to provide a methodology to inject credentials other than the current execution role into the Post call. This requires invoking STS AssumeRole to get new credentials against the targeted role arn and providing those to the Post call. This could be expanded upon to provide alternate posting methodologies to support self hosted elasticsearch but that would also require either a non-aws post function call with the necessary authorization headers/information or rework of the existing post function call to determine which authorization headers/information need to be sent.
🎯 Goal
Good security isolation would indicate to leverage multiple AWS accounts for serverless services. By separating out the accounts, you limit blast radius. However, in doing so you also want to have an account that can handle centralized log aggregation of some kind. Elasticsearch is a good target for that. This change would allow you to use the plugin as is, provide an environment variable for the role arn to assume, and provide for cross-account ESHttpPost calls.
💡 Possible Solutions
#429 is a possible solution. I have tested and used it in the VPC elasticsearch configuration with vpc peering in place and assuming a role in the elasticsearch account which is separate from the serverless deployment account.