# Understanding Falco’s Kubernetes Audit Log Plugins

**URL:** <https://community.sysdig.com/t/understanding-falco-s-kubernetes-audit-log-plugins/677>\
**Category:** Falco\
**Created:** [August 20, 2025, 12:25pm UTC](https://community.sysdig.com/t/understanding-falco-s-kubernetes-audit-log-plugins/677 "2025-08-20T12:25:02Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![leogr](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@leogr](https://community.sysdig.com/u/leogr)\
**Post date:** [August 20, 2025, 12:25pm UTC](https://community.sysdig.com/t/understanding-falco-s-kubernetes-audit-log-plugins/677/1 "2025-08-20T12:25:02Z")

</div>

Since this is a recurring topic, I wanted to share a quick explanation about Falco’s Kubernetes audit log plugins. EKS is just one example, but the same principles apply to all K8s audit plugins.

- **Which plugin should I use?**  
All audit plugins are equivalent. They just differ in how they collect logs depending on the cloud.  
👉 On **EKS** , use **`k8saudit-eks`**.

- **How do I check the latest version?**

- **Do I need to pin versions in Helm?**  
Yes, if you don’t want to always follow the latest. You can set refs in your `falcoctl` config.

- **Do syscall events get enriched with audit log data?**  
No — syscall and `k8saudit` are separate data sources.  
👉 If you want syscall events enriched with Kubernetes metadata, check out the [`k8smeta` plugin](https://github.com/falcosecurity/plugins/tree/main/plugins/k8smeta).