Upstreaming network.IP/CIDR to CEL-go from kubernetes #1238
Conversation
|
/gcbrun |
1 similar comment
|
/gcbrun |
…server implementation
|
/gcbrun |
ext/network.go
Outdated
|
|
||
| var ( | ||
| // Definitions for the Opaque Types | ||
| networkIPType = types.NewTypeValue("network.IP", traits.ReceiverType) |
There was a problem hiding this comment.
You can omit the traits.ReceiverType here and below. It implies the type implements the Receive method which it doesn't.
ext/network.go
Outdated
|
|
||
| var ( | ||
| // Definitions for the Opaque Types | ||
| networkIPType = types.NewTypeValue("network.IP", traits.ReceiverType) |
There was a problem hiding this comment.
Prefer creating an types.OpaqueType since these are types which do not have any fields accessible.
ext/network.go
Outdated
| networkCIDRType, | ||
| ), | ||
| // 2. Register Adapter (Bundled here so it applies automatically) | ||
| cel.CustomTypeAdapter(&networkAdapter{ |
There was a problem hiding this comment.
Prefer instead to create an inline cel.EnvOption like so:
func (e *cel.Env) (*cel.Env, error) {
adapter := &networkAdapter{Adapter: e.CELTypeAdapter()}
return cel.CustomTypeAdapter(adapter)(e)
}| Adapter: types.DefaultTypeAdapter, | ||
| }), | ||
| // 3. Register Functions | ||
| cel.Function(isIPFunc, |
There was a problem hiding this comment.
I would be very happy if we used the K8s content verbatim here (modulo some simple renames) as it'll simplify cost-tracking checks which K8s is doing presently and which someone will also need to upstream before making the improvements available to K8s to use.
The primary cleanup would be to shift from an IP library to a Network library which aggregates the K8s library/ip.go and library/cidr.go since we'd very likely always use them together.
2 participants
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.).