Configurable capture filter based on k8s pod and/or namespace?

[JamieDanielson]

Is your feature request related to a problem? Please describe.

There may be scenarios where folks only want specific namespaces or pods included in telemetry. This is also an option for limiting resource usage if needed.

[JamieDanielson]

Probably easiest to start with something like K8S_NAMESPACE_LIST/FILTER, where a list of namespaces can be provided that, to start, are excluded. And then we can add an option that the list is either for include or exclude.

The purpose of this agent is to tell you about everything, and maybe things you don't even know about. If for security reasons or because the telemetry is unnecessary for some namespaces (maybe instrumented with otel already), you can have an exclude list.

[MikeGoldsmith]

Adding a filter is more complicated than first thought and could be accomplished in two ways, each with pros and cons.

Capture

Option 1: BPF filter

Use the k8s client to get a list of pod IPs and use to form part of the bpf filter (eg not host 1.2.3.4 or not host 4.3.2.1 etc). This is the most effcient because the packets that we aren't interested in are not handed over to the agent from the capture source. How, the k8s client would need to watch for pod changes (add, remove) and signal for the bpf filter to be regenerated and applied to the capture handle. Also, a bpf filter has a maximum length, so applying a many hundreds of pod IPs to ignore could reach the maximum.

Option 2: Ignore when receiving packet

When a packet is received from the capture source, lookup the source & destination IPs and decide if we should continue to handle the packet (eg pass into assembler). This is less efficient than option 1 because packets we don't want will still be captured but this is the earliest opportunity we can ignore them and wouldn't need to recompute & apply a bpf filter.

Option 3: Drop in event handler

This is the easiest but least efficient option. The event handler already has access to a complete event and uses the k8s client to lookup additional k8s metadata.

Deciding what to drop

The second part of the question is more challenging, what traffic should we drop? There are three types of traffic:

• external -> pod
• pod -> pod
• pod > external

Should we omit traffic when one or both IPs are part of the excluded namespace?
What if one of the IPs is external or assigned to a service instead of a pod?

Initial PR and comment that make us pause and think before continuing:

• feat: Add config option to filter events based on namespace #278 (comment)

[MikeGoldsmith]

Moving out of beta, we're going to wait for additional feedback before implementing.

The following PR can still be used as a reference when we come back to this issue.

• feat: Filter events from namespaces #294

[robbkidd]

New Option: filter based on pod annotations.