Hello sir! Couple ideas, you could add the splunk user to a group, and set group permissions on the log so that the user could read it. Also, you could forward out the events via syslog to a system that does have a forwarder running in such a way as it can read the logs.
Or to add an another solution. You can add an acl on that particular file.
All the complexities and workarounds associated with not running Splunk as root can be avoided by simply running it as root but securely using SELinux: https://github.com/doksu/selinux_policy_for_splunk
There are also a number of other added benefits with this approach. When the SELinux policy is applied to Splunk, it protects it from other services that may have been compromised and vice versa. Furthermore, in a PaaS environment, you can use this SELinux policy to easily apply RBACs, delegating only the permissions required to manage the Splunk service as root. I haven't yet formally published this guide, but here's the working draft: https://github.com/doksu/selinux_policy_for_splunk/issues/5
Also, be sure to collect the audit log events using a normal inputs.conf monitor stanza rather than the nix app's scripted input. The nix app's scripted input modifies audit events in resolving uids; the script doesn't always work well and its functionality is superseded by the Linux Auditd app's uid resolution at search time (best practice).
This sounds like the best way to move forward. I hope you wil publish your guide in a finalized 1.0 version and will propose this in our organisation.
I agree this is a great idea for RHEL or CentOS - but the original poster doesn't say which Linux distro they are using.
I'm not convinced this solution would be ideal using a distribution which uses Apparmor (even though Apparmor profiles are simpler to write) because it doesn't provide the same level of confinement.