Upstreaming network.IP/CIDR to CEL-go from kubernetes

[tdesrosi]

Upstream CIDR and IP-related functions from kubernetes into cel-go

This is part of a broader effort to bring network functions from the kubernetes
project into CEL specifications upstream. This is related directly to
issues/1237.

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.).

[tdesrosi]

/gcbrun

[TristonianJones]

/gcbrun

[TristonianJones]

FYI @cici37 @jpbetz

[TristonianJones]

/gcbrun

[TristonianJones]

/gcbrun

[tdesrosi]

A note about these changes: To maintain strict AST-level compatibility with k8s, I'm going with a split registration pattern (declaring signatures in CompileOptions and bindings in ProgramOptions), rather than bundling them in CompileOptions via cel.Function.

When using the modern cel-go helper cel.Function() to register both the global overload (ip(string)) and the member overload (cidr.ip()) simultaneously, the internal dispatcher validation incorrectly flags the self-referencing overload ID "ip" as a collision (overload already exists).

To resolve this collision with the modern helper, we would be forced to rename the overload ID to something distinct like "ip_string". While functionally equivalent, this breaks strict parity with the Kubernetes AST reference data. If requested, we can go this route (and maintain parity minus the "ip" --> "ip_string" difference in overload IDs).

[TristonianJones]

/gcbrun

[TristonianJones]

A note about these changes: To maintain strict AST-level compatibility with k8s, I'm going with a split registration pattern (declaring signatures in CompileOptions and bindings in ProgramOptions), rather than bundling them in CompileOptions via cel.Function.

Actually, there really isn't any difference here between how the bindings are configured. K8s stages it a little differently, but it's materially identical between the two approaches.

When using the modern cel-go helper cel.Function() to register both the global overload (ip(string)) and the member overload (cidr.ip()) simultaneously, the internal dispatcher validation incorrectly flags the self-referencing overload ID "ip" as a collision (overload already exists).

It looks like the function ip overloads aren't properly configured as the overload_id values don't match those in K8s. Take another look as the two overloads in K8s are cidr_ip and string_to_ip.

It's worth looking at the other overloads as well.

[tdesrosi]

Thanks Tristan, here's one more pass rechecking overloads and member overloads.

[TristonianJones]

I've raised google/cel-spec#507 to cel-spec, so shortly after both artifacts are checked in and a new cel-spec release cut, let's enable the conformance tests

[TristonianJones]

Optional, but consider introducing static validators for ip and cidr conversions from string literals as this will save people a lot of trouble with runtime errors which could have been caught at compile time.

cel-go/cel/validator.go

Lines 261 to 279 in e9f15ea

	// Validate searches the AST for uses of a given function name with a constant argument and performs a check
	// on whether the argument is a valid literal value.
	func (v formatValidator) Validate(e *Env, _ ValidatorConfig, a *ast.AST, iss *Issues) {
	root := ast.NavigateAST(a)
	funcCalls := ast.MatchDescendants(root, ast.FunctionMatcher(v.funcName))
	for _, call := range funcCalls {
	callArgs := call.AsCall().Args()
	if len(callArgs) <= v.argNum {
	continue
	}
	litArg := callArgs[v.argNum]
	if litArg.Kind() != ast.LiteralKind {
	continue
	}
	if err := v.check(e, call, litArg); err != nil {
	iss.ReportErrorAtID(litArg.ID(), "invalid %s argument", v.funcName)
	}
	}
	}

[tdesrosi]

Since the helper in cel/validator.go is not exported, I created a networkFormatValidator directly in network.go that mimics its behavior with AST tools. Is something like this what you had in mind?

[jpbetz]

@lalitc375

[jpbetz]

The cost calculations for this library exist in https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/cel/library/cost.go in the Kuberhetes code. Is it possible to also upstream the cost calculations?

[TristonianJones]

Yep, I'll tackle this after the initial implementation is in