Closed flavio closed 3 years ago
I've created this simple CLI tool that scans a directory recursively and analyzes all the Rego file it finds. For each file, the tool identifies the built-ins that must be provided by the SDK. Finally the tool provides an overview of all the SDK dependent built-ins found, and how many Rego files are actually referencing them.
I ran the tool against the gatekeeper and the OPA library repositories. The results are shown below.
Running the tool against a checkout of the repository produces the following output:
Rego files analyzed: 29
List of builtins that have to be provided by the SDK
NAME OCCURRENCES
sprintf 28
That means the 28/29 files are using the sprintf
built-in. Note well: the function could be used more than once per file, but we don't care about that.
This repository contains multiple folders. Each folder has a specific use case in mind: Kubernetes, terraform, AWS, Istio,...
Right now we care only about the Kubernetes policies. Pointing the tool against the kubernetes directory produces the following output:
Rego files analyzed: 19
List of builtins that have to be provided by the SDK
NAME OCCURRENCES
sprintf 5
cast_array 1
http.send 1
Something worth of note: the cast_array
built-in function cannot be found inside of the official built-ins documentation.
I think we can consider this card done.
The Rego languge provides a series of functions that can be used by policy authors, these are called "built-ins".
Some of these built-ins are automatically "bundled" with the final Wasm file, others have to be provided by the WebAssembly execution host.
This page provides a list of all the built-ins offered by OPA. The "Wasm support" column clearly states which ones are automatically provided (:white_check_mark:) and which are instead "SDK-dependent".
Goals of this issue: identify the most used Rego built-ins
This can be achieved by looking at the policies defined here:
This is part of https://github.com/kubewarden/policy-evaluator/issues/14