Skip to content

Cedar analysis design propositions

Jump to bottom
Safin Wasi edited this page Sep 11, 2025 · 1 revision

This wiki page is to document different options to integrate cedar's analysis tools into Agama Lab, and current limitations of those options.

Option 1: Python Binding

This option involves creating a python binding around cedar-policy-symcc, and using the binding interface to call cedar's analysis functions from Agama API. The API would then expose endpoints for the frontend to call and respond with analysis results.

Limitations

The Agama API backend runs on Alpine Linux based containers, which implements muslc instead of glibc which is common in many distributions. The build tool for creating Python bindings for Rust projects, maturin, does support compiling against musl C platforms. To ensure portability, the built artifacts are dynamically linked to a set of shared libraries. Musl C, however, was designed for static linking. This leads to the binding not being able to find shared libraries and erroring:

test-1  | Skipping virtualenv creation, as specified in config file.
test-1  | Traceback (most recent call last):
test-1  |   File "/api/example.py", line 6, in <module>
test-1  |     from cedarling_python import BootstrapConfig
test-1  |   File "/usr/local/lib/python3.10/site-packages/cedarling_python/__init__.py", line 1, in <module>
test-1  |     from .cedarling_python import *
test-1  | ImportError: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/local/lib/python3.10/site-packages/cedarling_python/cedarling_python.cpython-310-x86_64-linux-gnu.so)

Even with a compatibility layer like gcompat or libc6-compat, the binding cannot run on this platform:

ImportError: Error relocating /usr/local/lib/python3.10/site-packages/cedarling_python/cedarling_python.cpython-310-x86_64-linux-gnu.so: gnu_get_libc_version: symbol not found

Solutions

As this is a platform-dependent issue, the simple alternative is not to use an Alpine Linux based container. However, this can have security and infrastructure implications, as this would involve rewriting our docker build process.

Option 2: Cedar Lean CLI

This option involves installing cedar-lean-cli on the same container as Agama API, and calling the CLI internally. Agama API would expose endpoints for the frontend to call, and respond with results after calling the CLI.

Limitations

The biggest problem with this approach is error handling. Without a dedicated error parser, Agama API cannot know what error the CLI failed on and can only respond with the output. Furthermore, improper error handling may cause the calling program i.e. Agama API itself to crash. There is no static binary published for cedar-lean-cli. The documentation recommends building from source to install it on a local machine, but one of the requirements, elan(Lean's version manager) is unsupported on musl-based systems:

image

cedar-lean-cli itself is linked dynamically against glibc:

$ ldd cedar-lean-cli
	linux-vdso.so.1 (0x00007f45409f3000)
	libleanshared.so => not found
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f4540986000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f4540878000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f453f400000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f45409f5000)

This leads us back to the limitations and solutions in Option 1.

Option 3: WASM

This option would involve developing a WASM binding around cedar-policy-symcc and delegating the analysis entirely to the frontend.

Limitations

The limitation for this approach is efficiency, as a backend container would be able to run analysis more efficiently than a JavaScript application running a WASM binary.

Additional Notes

The current release of cedar as of this writing (4.5.1) does not contain cedar-policy-symcc. Regardless of what option we choose, we need a published version of cedar containing this crate to develop a binding.

Clone this wiki locally