SYSTEM Cited by 1 source
Netflix SEL (Simple Expression Language)¶
SEL — the Simple, Secure, and Safe Expression Language — is Netflix's homemade expression language for safe code injection inside Maestro parameterized workflows. SEL is a subset of the Java Language Specification (JLS) focused on Maestro use cases: all Maestro parameter types, datetime handling, error-raising, predefined utility methods. Source code + docs at github.com/Netflix/maestro/blob/main/netflix-sel.
Why a homemade expression language¶
Maestro supports parameterized workflows where users define dynamic parameters + conditional logic in their workflow definition. This flexibility enables complex use cases — backfill pipelines, conditional-branch audit-remediate flows, state sharing between upstream and downstream steps — but introduces code injection into the orchestrator's process.
"However, code injection introduces significant security and safety concerns. For example, users might unintentionally write an infinite loop that creates an array and appends items to it, eventually crashing the server with out-of-memory (OOM) issues." (Source: sources/2024-07-22-netflix-maestro-netflixs-workflow-orchestrator)
Netflix explicitly considered + rejected the alternative of pushing parameter-expression logic into user business logic (outside the workflow definition):
"While one approach could be to ask users to embed the injected code within their business logic instead of the workflow definition, this would impose additional work on users and tightly couple their business logic with the workflow. In certain cases, this approach blocks users to design some complex parameterized workflows."
Instead: build a safe subset of Java that users can inject into the workflow definition itself, with runtime enforcement preventing the "accidental OOM" and similar threats.
Design stance¶
Subset of the Java Language Specification¶
SEL borrows its grammar and syntax from JLS, so Java-literate Netflix engineers can use it without learning a new language. Supports:
- All Maestro parameter data types (string, number, boolean, datetime, maps, lists — whatever the step-runtime parameter types require).
- Error raising (fail a step via expression evaluation).
- Datetime handling (first-class date/time types, used heavily in backfill + scheduled pipelines).
- Predefined utility methods (Maestro-curated set).
Syntax-tree validation at parse time¶
"SEL supports code injection while incorporating validations during syntax tree parsing to protect the system."
Static validation before execution — expressions that violate policy at the syntax level are rejected before they ever run.
Runtime limits¶
Even after syntax-tree validation, dynamic behaviour is bounded by three explicit runtime checks:
- Loop iteration limits — prevent infinite loops.
- Array size checks — prevent unbounded array growth.
- Object memory size limits — prevent any single evaluation from consuming arbitrary memory.
These are the specific threats the Netflix team enumerated in the post; SEL's runtime enforces them structurally, not via per-expression hand-written guards.
Java Security Manager sandbox¶
"It leverages the Java Security Manager to restrict access, ensuring a secure and controlled environment for code execution."
SEL evaluation runs inside a Java Security Manager context that restricts the JVM capabilities available to injected expressions — filesystem access, network IO, reflection, class loading, thread spawning, etc. — closing the substantial residual capability surface of a JLS-subset evaluator.
Architecture sketch¶
┌─────────────────────────────────────────────────────────────┐
│ User workflow definition (JSON) │
│ ... │
│ "expression": "foreach partition in dateRange(...): ..." │
│ ... │
└──────────────────────┬──────────────────────────────────────┘
│ parsed at workflow-registration time
▼
┌────────────────────┐
│ SEL syntax-tree │ rejects disallowed
│ validator │ JLS constructs
└────────┬───────────┘
│
▼
┌───────────────────────────┐
│ Runtime interpreter │
│ · loop-iteration limit │
│ · array-size limit │
│ · memory-size limit │
└────────┬──────────────────┘
│ inside
▼
┌───────────────────────────────┐
│ Java Security Manager sandbox │
│ · no filesystem access │
│ · no network IO │
│ · no reflection │
│ · no class-loading │
└───────────────────────────────┘
Why this pattern generalises¶
The SEL design is a canonical wiki instance of patterns/sel-sandboxed-expression-language — homemade domain-specific subset of a mainstream language, with runtime limits + platform sandbox, enabling safe code injection at a security boundary. Same shape as:
- Kubernetes CEL (Common Expression Language) for admission controllers — Google-built subset of cc-like expression language with bounded evaluation.
- OpenPolicyAgent Rego for policy-as-data.
- AWS IAM policy conditions.
The SEL instance specifically canonicalises the workflow- orchestrator variant where the threat is tenant-workflow code crashing the shared orchestrator process (OOM, infinite loop), not tenant workflows escaping to a privileged context.