Hi everyone, I'm pretty new to Sysdig and we're in the middle of migrating our monitoring and security from a couple of older tools. I've been tasked with setting up some custom Falco rules for our containerized workloads in the Sysdig SaaS console, but I'm hitting a wall and it's starting to stress me out.
I followed the documentation to create a custom rule in the "User Rules" section of the console. The rule is supposed to alert when a specific, non-standard binary is executed inside any container. The rule seems to save okay, and the policy is attached to our scope, but we're never getting any alerts, even when I manually trigger the condition. The default rules work fine, so I know the agent is communicating.
My rule looks something like this:
- rule: My Custom Binary Execution
desc: Alert on execution of our custom tool
condition: spawned_process and container and proc.name="our-custom-tool"
output: "Custom tool executed (user=%user.name command=%proc.cmdline container=%container.info)"
priority: WARNING
Could the issue be with the scope or the notification channel? Or is there a delay I'm not aware of? I'm worried I've misunderstood how the SaaS console applies these user rules versus the open source Falco way. Any step-by-step guidance on what to check next would be a lifesaver. I really need to get this working to prove our migration is on track. 😅
One step at a time
Oh, the classic "why isn't my custom Falco rule firing" despair, we've all been there. Your rule syntax looks correct for a simple proc.name match, so the issue is almost certainly in the SaaS console's policy layer, not the Falco engine itself.
The console saves rules and attaches policies silently, but there's a hidden order of operations that trips everyone up. Did you check the "Enabled" toggle on the actual policy after attaching it to your scope? It's separate from the rule being saved, and it defaults to off sometimes. Also, the scope attachment is finicky - if your test container isn't tagged/labeled exactly as defined in the scope's filters, it'll ignore the event entirely.
The delay is minimal, but there's a bigger gotcha: the condition `container` means it's running *inside* a container. If you're testing from the host node shell, it won't trigger. You have to exec into a pod and run the binary.
Try this: create a dumb rule that alerts on `proc.name="sh"` or something ubiquitous, attach it, enable the policy, and exec into a container and run `sh`. If that fires, your plumbing works and the original rule's `proc.name` value might just be wrong (maybe it's `our-custom-tool.bin` or a symlink). If the dumb rule also doesn't fire, the policy attachment is broken.
Demos are just theater. Show me the real workflow.
Yeah, that rule syntax looks solid for what you're trying to catch. Been there!
The user who mentioned the policy "Enabled" toggle is spot on - that one gets me every time. I'd also double-check your scope's actual filters against the container you're testing in. If you're using Kubernetes labels or image name filters, a small typo means it won't apply.
Also, for a quick test, try changing your condition to just `spawned_process and proc.name="our-custom-tool"` to see if it's the `container` part that's unexpectedly filtering things out. Sometimes the container detection logic can be a bit picky depending on the runtime.
Less hype, more data.