search

aquasecurity / tracee

Linux Runtime Security and Forensics using eBPF
https://aquasecurity.github.io/tracee/latest
Apache License 2.0
3.35k stars 394 forks source link

Add Kubernetes filters to scopes #3711

Open michaelkatch opened 7 months ago

michaelkatch commented 7 months ago

As of today, when using tracee on k8s we can filter events based on the pod namespace (as attached on the picture) image

Lately, we have encountered numerous situations where we need to trace events and signatures only from a specific pod namespace. Cloud you please add this ability to the scope so we could filter the whole policy? Attaching the desired outcome: image

Thank you

NDStrahilevitz commented 7 months ago

I think all of our kubernetes fields would be useful for scope filtering so may as well generalize the issue, especially since they are all userspace filters. However, we currently don't have userland scope filters so this can either be done as part of #2675 or on its own. Also related: #3553.

rafaeldtinoco commented 7 months ago

I think all of our kubernetes fields would be useful for scope filtering so may as well generalize the issue, especially since they are all userspace filters. However, we currently don't have userland scope filters so this can either be done as part of #2675 or on its own. Also related: #3553.

I would say https://github.com/aquasecurity/tracee/issues/2675 should be related to the trie datasource for in-kernel string filtering with wildcards we discussed.

Maybe this issue can be a issue to treat ANY event context filter in scopes ? This would be like adding the filters=XXX to all all filters within a policy, correct ? @geyslan should also take a look at this one.

geyslan commented 7 months ago

I think all of our kubernetes fields would be useful for scope filtering so may as well generalize the issue, especially since they are all userspace filters. However, we currently don't have userland scope filters so this can either be done as part of #2675 or on its own. Also related: #3553.

I would say #2675 should be related to the trie datasource for in-kernel string filtering with wildcards we discussed.

Maybe this issue can be a issue to treat ANY event context filter in scopes ? This would be like adding the filters=XXX to all all filters within a policy, correct ? @geyslan should also take a look at this one.

Yes, they're all related. The ultimate goal is to convert all (or the majority of) filters to bpf land. But @michaelkatch I wonder if it's not currently possible to do what you asked for:

Cloud you please add this ability to the scope so we could filter the whole policy?

@josedonizetti, are policies able to define filters in the mentioned way?

NDStrahilevitz commented 7 months ago

@josedonizetti, are policies able to define filters in the mentioned way?

Not Jose, but we have the scope section, this would go there. But these fields aren't defined for that section right now if that's what you asked.

I would say https://github.com/aquasecurity/tracee/issues/2675 should be related to the trie datasource for in-kernel string filtering with wildcards we discussed.

I think the trie would be how this is implemented, not sure how the data sources feature relate to this.

Maybe this issue can be a issue to treat ANY event context filter in scopes ? This would be like adding the filters=XXX to all all filters within a policy, correct ? @geyslan should also take a look at this one.

I agree, I think the current separation should be fixed if we can. That way any new filter we add can be easily applied both ways.

rafaeldtinoco commented 7 months ago

I think the trie would be how this is implemented, not sure how the data sources feature relate to this.

I meant data structure =D (dyslexia won).