Allow configuring policy filter map size

[kyledong-suse]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your feature request related to a problem?

Currently, Tetragon limits the number of concurrent policies to 128 in the ebpf program for policy_filter_maps:

#define POLICY_FILTER_MAX_POLICIES   128

struct {
	__uint(type, BPF_MAP_TYPE_HASH_OF_MAPS);
	__uint(max_entries, POLICY_FILTER_MAX_POLICIES);
	__type(key, u32); /* policy id */
	__array(
		values, struct {
			__uint(type, BPF_MAP_TYPE_HASH);
			__uint(max_entries, 1);
			__type(key, __u64); /* cgroup id */
			__type(value, __u8); /* empty  */
		});
} policy_filter_maps SEC(".maps");

The current cap is too restrictive. Users operating with large policy sets can quickly reach this limit, causing subsequent policies to be dropped or rejected.

Describe the feature you would like

The idea is to make the policy filter map size configurable like execve_map

Describe your proposed solution

• Replace the fixed __uint(max_entries, POLICY_FILTER_MAX_POLICIES) with __uint(max_entries, 1) in bpf/process/policy_filter.h
• Add a new option flag "policy-filter-map-entries" refers to existing implementation for execve-map-entries
• Default the map entries to 128 to remain backward compatible
• Let the agent set spec.Maps["policy_filter_maps"].MaxEntries before program is loaded, based on the new configuration value

This proposal will

• Removes the static 128-policy cap.
• Enables dynamic scaling of policy capacity and gives users the flexibility to configure limits according to their deployment scale.
• No verifier or eBPF logic changes required.
• Backward compatible (defaults remain unchanged).

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[kyledong-suse]

Hi @mtardy, just wanted to follow up on this issue to see if there’s been any update or thoughts from the team.

I’ve been revisiting this recently and still seeing the same limitation. Wondering if this is on the radar or if there’s a known workaround. If it helps, I can try to provide more logs or a minimal reproducer. Please let me know what would be most useful.

Thanks again for your time!

[kkourt]

Hi,

I think the issue is pretty obvious so I don't think there is a reason for a reproduction. One thing to note is that the limitation does not include all policies, just policies with k8s segmentation primitives (i.e., either podSelectors or namespaced policies).

Having a way to configure the map size statically at agent startup time is reasonable, and should be relatively easy to implement.

Having dynamic scaling seems like a more involved problem, though, and we would need to discuss an approach.

[kyledong-suse]

@kkourt, thanks for confirming, and that makes sense. I'd like to prepare a draft to implement what I mentioned in the proposed solution. Does that sound good to you?