OpenUBA v0.0.2: An Open-Model UEBA Framework Built on Kubernetes

The black-box problem OpenUBA is answering

The README states the problem directly: many UBA platforms use a black-box approach to data science and treat their models as intellectual property. That works for analysts who only want a queue of anomalies, baselines and cases. OpenUBA targets what the project itself calls a small subset of security analysts who want to know what a model is doing under the hood. The stated motivation is transparency for compliance, response and investigation, and decision making. So the intended user is not a SOC tier-1 triage analyst. It is a detection engineer or data scientist who is comfortable reading Python, and who has been asked to justify why an alert fired. The secondary audience is model authors: the README describes a community-driven marketplace, similar to a plugin store, where models are the plugins, developers can upload them, and pricing (free or paid) is left to the developer. That marketplace framing is the most ambitious part of the pitch and also the least verifiable from the material here, since the README does not document the marketplace service, its review process, or where uploaded models are hosted.

What actually runs: operator, CRDs and ephemeral jobs

The architecture is Kubernetes-native and the README is explicit that there are no always-on per-model services and no heavy pipeline orchestrators. Instead a custom operator built with Kopf watches two custom resources, UBATraining and UBAInference, and creates ephemeral Jobs when either changes. Those jobs run framework-specific Docker images, and the README names sklearn, pytorch and tensor as examples. Data flows through three stores with distinct roles: PostgreSQL is the system of record, Elasticsearch handles search and analytics, and Apache Spark provides distributed compute, all backed by Persistent Volumes. The API surface is split. FastAPI exposes REST endpoints with JWT authentication plus model orchestration, the rule engine and scheduling. PostGraphile auto-generates a GraphQL API from the PostgreSQL schema, which is what enables subscriptions and the real-time frontend. The frontend is a Next.js 14 React application using TailwindCSS and shadcn/ui. The design consequence worth noting: because inference is a batch job rather than a resident service, model startup cost is paid on every run, and anything stateful has to live in PostgreSQL or Elasticsearch rather than in process memory.

Getting a local instance up

The README points developers at a Kind cluster for development and a production Kubernetes cluster for deployment, and it references a Makefile reference section and a docker-publish GitHub Actions workflow, so the intended path is make targets rather than a long sequence of kubectl commands typed by hand. It also states that all components are containerized and that images are published under the openuba Docker Hub organisation. What the supplied material does not give is the literal target names, the Helm chart or manifest paths, or the environment variables for the FastAPI service. If you are evaluating this repo, read the Makefile and the docker-publish workflow before anything else, because those two files define the real install path. The runtime floors you can confirm from the badges are Python 3.11+, TypeScript 5.x, FastAPI 0.100+, Next.js 14+, PostgreSQL 15+, Elasticsearch 8.x, Spark 3.x, and Linux or macOS as the platform. Kubernetes is described as native but no minimum version is stated anywhere in the material.

Rule Canvas and the model library as the analyst-facing layer

Two named features carry the transparency claim. Rule Canvas is listed as a top-level feature and appears in the table of contents, but the README body supplied here does not describe its editor model, its output format, or how rules are persisted. Model Library is similarly listed without a schema. What can be inferred from the architecture is the shape: rules and models are the two artefacts an analyst authors, the rule engine lives in the FastAPI backend, and models are executed as jobs rather than loaded into the API process. That separation is a sensible choice for security work, since a model that imports TensorFlow should not be able to take down the API. It also means the feedback loop between editing a rule and seeing it fire runs through PostgreSQL and Elasticsearch, not through an in-process debugger. The README's Model Execution Sandbox section is listed in the contents but its body is not included in the material, so any claim about isolation strength (namespace, seccomp, network policy) would be speculation.

Where OpenUBA is the wrong tool

Three limitations are visible without running anything. First, the project is tagged BETA in its own description and the only release in the material is v0.0.2-r1, dated 2026-02-18, for a version line that starts at 0.0.2. There is no stated compatibility guarantee between releases, and no migration guide is referenced. Second, the operational surface is large for a security tool: Kubernetes with a custom operator, PostgreSQL, Elasticsearch, Spark, plus per-framework Docker images. A team without an existing cluster is signing up to run four stateful systems to get behaviour analytics. Third, the GraphQL layer is generated by PostGraphile from the PostgreSQL schema, which means the database schema is effectively the public API contract. Schema changes are not just migrations, they are API changes, and the README gives no versioning policy for that surface. If your organisation needs a vendor to page at 3am, or needs a documented detection accuracy figure before purchase, this is the wrong shape of project regardless of how good the model library is.

How this differs from a commercial UEBA suite

The obvious comparison is a commercial UEBA product, and the README frames the difference itself: those platforms treat models as IP, OpenUBA treats them as plugins you can read and replace. The practical consequences are concrete. With a commercial suite you get a tuned baseline, a support contract and an accuracy number you can put in a risk register, but you cannot open the scoring function. With OpenUBA you get the scoring function in Python, running in a job you control, against data in PostgreSQL and Elasticsearch you already own, and you own the tuning. The cost shifts from licence to engineering time. There is a second, less obvious difference: because inference is a Kubernetes Job rather than a service, you can pin a model to a specific image with a specific library version, which matters when a detection depends on a particular sklearn release. A hosted suite gives you no such pin. The trade is that nobody else is testing your combination of image tag, cluster version and Elasticsearch mapping.

Maintenance, licensing and what the Apache-2.0 grant does not cover

The repository is licensed Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not grant trademark rights, so you cannot present a fork as OpenUBA, and it provides no warranty. Two things sit outside that licence and are worth flagging before you build a dependency on them: the README describes a marketplace where model developers may charge for their models, so individual models may carry their own terms even though the framework does not, and the LLM Assistant feature listed in the contents is not described in the material, so its data handling and any third-party API dependency are unknown. On upgrade cost, the material supports only a limited statement: the last push is 2026-08-22 and the only release listed is v0.0.2-r1 from 2026-02-18, so the project is active but the release cadence is not established by a single data point. Because PostGraphile derives GraphQL from the schema, budget for schema migration work on every upgrade, not just for dependency bumps. This is a description of the licence terms, not legal advice; have counsel review the marketplace terms if you intend to redistribute models.

Editorial conclusion

Adopt OpenUBA if you already run Kubernetes, Elasticsearch and PostgreSQL, and if your analysts want to read and edit the detection logic rather than consume a vendor score. Do not adopt it if you need a supported product with a published accuracy record or if your team cannot operate a Kind cluster and a Spark execution plane. Before committing, verify three things against the repository: whether the marketplace backend is actually part of this repo or an external service, which Docker image tags the operator pulls for sklearn and TensorFlow jobs, and whether the v0.0.2-r1 release notes list breaking schema changes from v0.0.1.

Official sources

1. GACWR/OpenUBA on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases