K8sNativeValidation and SyncSets

[dgr237]

I am currently looking at developing some validation constraints which for a ClusterRoleBinding needs to check labels on the namespace associated with the Service Account that the ClusterRole is being bound to.

I was looking to use the K8sNativeValidation rules rather than rego and could not find an example on how this could be used. I developed the expressions which I was testing with GatorCLI and I get the error 'undeclared reference to 'data' (in container '').

Is the use of SyncSets possible with K8sNativeValidation and if so do you have an example on how I could check if a label on the namespace associated with a ServiceAccount in a ClusterRoleBinding matches a required label?

[JaydipGabani]

@dgr237 As far as I know, SyncSets (referential validations) are only available with the policies using rego. @ritazh @maxsmythe Please correct me if I am wrong here.

[dgr237]

@JaydipGabani Thanks for confirming. This is what I suspected. Is this something which is on the roadmap?

[JaydipGabani]

@dgr237 I am not sure if CEL is capable of handling such kind of complex logic to begin with. @maxsmythe @ritazh would be able to better answer about the roadmap for k8snativevalidation.

[maxsmythe]

CEL should syntactically be able to handle referential data. A straw man example might be:

dataCache.List({
  "kind": "Pod"
}).all(pod, pod.metadata.name != object.metadata.name)

Where the above is listing all pods and making sure they don't have the same name as the inbound object.

A few caveats:

• This is a rough sketch of what might be possible -- more design would be needed for a serious effort
• We probably would not do this with the K8s native CEL engine. Since that is intended to be able to generate VAP resources to handle admission enforcement, we should avoid supporting features VAP will not support (like referential constraints). Of course, nothing prevents us from using CEL in a different engine that is less coupled to VAP, which would unblock support here.
• This is something that can likely be done, but is a non-trivial amount of work. I'd definitely like signal from users to help indicate priority here, if this is a thing people would want to see.

Last design consideration: this cache should be one that can be shared across all engines (including Rego). This will help to avoid excess RAM usage.

[ritazh]

@dgr237 thanks for raising this.

I was looking to use the K8sNativeValidation rules rather than rego

I'm curious, can you please share why you did not want to rego since it already supports referential policies quite well?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.