Hi everyone, I'm working with the Splunk Add-on for AWS on Splunk Cloud, and I’ve run into an issue when trying to collect CloudWatch Logs from a cross-account AWS setup. After digging through the ...
See more...
Hi everyone, I'm working with the Splunk Add-on for AWS on Splunk Cloud, and I’ve run into an issue when trying to collect CloudWatch Logs from a cross-account AWS setup. After digging through the Python code inside the add-on, I discovered that it uses the logGroupName parameter when calling describe_log_streams() via Boto3. However, in cross-account scenarios, AWS requires the use of logGroupIdentifier (with the full ARN of the log group) — and you can’t use both parameters at the same time. So, even though AWS allows log collection across accounts using logGroupIdentifier, the current implementation in the add-on makes it impossible to use this feature correctly. I was able to identify the exact line of code that causes the issue and verified that simply replacing "logGroupName" with "logGroupIdentifier" solves the problem. Given that I'm on Splunk Cloud, I have a few questions for those with more experience in similar situations: Is it possible to modify that single line of Python code directly in the official add-on deployed in Splunk Cloud (maybe through the UI or some workaround), or is that completely locked down? I could clone the add-on, patch it, and submit it as a custom app — but would running a custom version of the AWS add-on cause issues with future Splunk Support cases? (i.e., would support be denied for data coming from a modified TA?) More broadly, for anyone who’s set up Splunk in cross-account AWS environments: What’s your recommended approach for collecting CloudWatch Logs in this scenario, given the limitations of the official add-on? Thanks in advance for any insights.