Upstream kubernetes CIDR.contains functionality

[tdesrosi]

Feature request checklist

• There are no issues that match the desired change
• The change is large enough it can't be addressed with a simple Pull Request
• If this is a bug, please file a Bug Report.

Change

The basic premise is to match upstream functionality in kubernetes for CIDR/IP range built-in functions.

Kubernetes has implemented a robust set of CEL functions for handling IP addresses and CIDR ranges (e.g., isIP, cidr, ip, and containment checks). These are currently locked inside k8s.io/apiserver, but they are generally useful for any policy engine dealing with network logic (firewalls, access lists, etc.).

The implementation would introduce opaque types for IP and CIDR to ensure correctness, rather than treating them as raw strings.

Example

Match kubernetes functionality:

cidr('192.168.0.0/24').containsIP(ip('192.168.0.1'))

Alternatives considered

Using matches() for IP validation is error-prone and difficult to maintain (especially for IPv6). We also are using startsWith() in various places, but this makes CEL policies which check IP inclusion in a CIDR range long and repetitive.

Loading a WASM module for basic network logic is overkill and introduces performance overhead for simple checks.

Process

I (@tdesrosi) will being this work.

[gudvinr]

What's stopping you from just importing k8s.io/apiserver? Or copying same files into your project directly. CEL isn't only for networking applications so doesn't seem like a great idea to bloat standard library with stuff for specific domain.

And cel-go isn't the only implementation of CEL. When you share types with protobuf, you don't need per-language library implementation. But if one implementation has this specific library and other doesn't, you can't share expressions anymore.

[TristonianJones]

Hi @gudvinr, I've actually suggested copying the types and much of the implementation from K8s directly. Taking a dependency on k8s.io/server would lead to a circular dependency, and there's likely a portability aspect where we'll need to introduce something like a CIDR / IP interface to ensure future interop with K8s during a future CEL bump -- extensions are opt-in, but it would be great to have a single extension library for networking.

@tdesrosi is starting with cel-go given the history with K8s, but is looking to port the work to Java and C++. To support his effort, I'll be adding conformance tests to cel-spec to make sure there's no loss of functionality between the different implementations.

[gudvinr]

To support his effort, I'll be adding conformance tests to cel-spec to make sure there's no loss of functionality between the different implementations.

Sounds great if it's intended to be portable