Skip to content

CFP: Cilium policy selector expression#94

Draft
fristonio wants to merge 1 commit into
mainfrom
pr/fristonio/policy-selector-expressions
Draft

CFP: Cilium policy selector expression#94
fristonio wants to merge 1 commit into
mainfrom
pr/fristonio/policy-selector-expressions

Conversation

@fristonio
Copy link
Copy Markdown
Member

No description provided.

Signed-off-by: Deepesh Pathak <deepeshpathak09@gmail.com>
@fristonio fristonio force-pushed the pr/fristonio/policy-selector-expressions branch from 65eab75 to 56b17c0 Compare May 5, 2026 01:14
@fristonio fristonio requested a review from squeed May 5, 2026 03:30
@squeed
Copy link
Copy Markdown
Contributor

squeed commented May 6, 2026

Should we set a cost limit for CEL expressions? It could be caught in the Sanitize function().

We can always increase the cost limit, but never decrease it :-/.

@joestringer
Copy link
Copy Markdown
Member

Could you also draft some specific user stories about selections they would like to do? I think that would help to inform what the solution should look like in order to satisfy the intent of our users.

#### Option 2: CEL Expression

A more natural option for the use-case is to use CEL(Common Expression Language) based expression for label selectors. Cilium already imports the `cel-go` library and has experimental support for CEL based expression language in hubble filters. This option will give us the opportunity to build a strong foundation for CEL usage in Cilium project, allowing easier adoption for similar usecases in future.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably include some examples here, along with the expected CEL variables and functions we intend to expose.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of keeping the implementation details separate from the high level CFP. I am working on the implementation of CEL env here. Do you think it makes sense to keep this detailed documentation there(working on a package level README) or should I include everything here?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that the CEL environment is probably worth briefly discussing, since it's essentially unchangeable once landed. We don't need to consider every possible function

@squeed
Copy link
Copy Markdown
Contributor

squeed commented May 12, 2026

So, I'm thinking about the existing source:key convention for embedding sources in to keys. It works, but I don't particularly like it. In particular, the source is not part of the key. It is metadata attached to the value. (Side note: we get very lucky that 1.1.1.1/32 is not a valid k8s label, since we rely on that for CIDR selectors. In the future, I could even see us allowing multiple values for a given key, though this may not be worth the pain.)

Anyways.

From your comments, it seems that looking up labels via function calls is expensive. What the environment had a single variable, labels:

map[string]struct{
  Value string `cel:"value"`
  Source string `cel:"source"`
}

	env, err := cel.NewEnv(
		ext.NativeTypes(
			ext.ParseStructTag("cel"),
			reflect.TypeFor[*Label](),
		),
		cel.Variable("labels",
			cel.MapType(cel.StringType, cel.ObjectType("main.Label"))),
	)

We could even add some useful macros, like label(key) expanding to labels[key].value

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants