yeke.io · enterprise

Built for your team’s way of working.

Enterprise adds organizational sign-in, approval workflows, records and GitOps to YEKE. Explore available features, product screens and limitations below.

Request a demo Pricing
In the product today

Phase E1

Identity and compliance

Sign in with organizational accounts and export audit records to your SIEM.

  • Sign in with your directory. Users come from your own directory. You connect LDAP or Active Directory, and sign-in is verified there.
  • Group membership becomes Kubernetes identity. You write the mapping; an unmapped group carries no privilege.
  • The local sign-in path stays open. If the directory is unreachable, you can still get in.
  • OIDC SSO is in the same item. It works with Keycloak and Entra ID.
  • What it does not do: no SAML, no SCIM.

Connect a directory →  ·  Sign in with OIDC →

ldap directory · connected
The YEKE directory screen: an Active Directory record connected over LDAPS on port 636 — server address, base DN, bind DN, user filter, user attribute and the admin group DN side by side; below them, lines confirming that the connection test passed and that nested group membership is resolved
A connected directory: the filter, the admin group and a passed connection test.
  • SIEM export. Reading the audit trail is free on every tier; Enterprise adds export to external systems.
  • Two transports. syslog over TLS with a CEF body, and a signed webhook; unencrypted transport cannot be chosen.
  • Track export progress. Each destination has its own cursor. Records that cannot be verified are not silently skipped.

What we have not measured: end to end against an enterprise SIEM parser.

siem export · two targets
The YEKE SIEM export screen: two active targets — one a central SIEM carrying syslog over TLS with CEF, the other a webhook store with an NDJSON body. For each target the scope, start point, cursor, records sent and records still behind are written out column by column; both connection tests have passed
Two streams at once: scope on the left, cursor on the right.
In the product today

Phase E2

Scale and continuity

Prepare for production with PostgreSQL, HA, air-gap installation and archiving.

  • PostgreSQL driver. YEKE connects to a PostgreSQL you already run; it does not install one. Connect PostgreSQL →
  • HA for core. The console and API stay available during rolling updates. Cluster access may briefly disconnect while agents reconnect. HA setup →
  • Air-gapped install package. One signed package for a single machine; it never reaches the network. Air-gapped install →
  • Long retention and archive. A deleted operation is copied into the archive and stays readable. Retention and archive →
  • Migrating from SQLite to PostgreSQL. Offline and one way only; not tested at production volume. Database migration →
In the product today

Phase E3

Governance

Require a second approval for critical operations, define change freezes and report on changes.

Dual approval (four eyes)

  • Enable through policy. Choose which operations require a second approval.
  • A second person approves; the owner applies. Consent does not transfer ownership of the operation.
  • Consent is tied to the plan. A changed plan needs fresh consent.
approval card · requester's view
A YEKE approval card awaiting a second approval: an amber notice says two users can consent to the plan, that it cannot be applied until one of them does, and that the approver has to be in the 'sre' group. Below it the body of the plan — a diff table raising the replica count from 3 to 5, with dry-run-passed and revertable badges
The plan owner's card: how many people can consent.
approval card · approver's view
The same approval card after consent was given: at the top, a box saying the second approval has been received, by whom and when. The buttons at the bottom are only 'Cancel' and 'Withdraw my consent' — there is no apply button
The approver's card: even after consent, there is no apply button.

Maintenance window

  • A change freeze blocks apply. Retry when the window ends. If the plan has expired, create a new one.
  • A time zone is required. A window without one cannot be defined.
  • What it does not do: there is no way to break the glass yet.
approval card · change freeze
A red band on a YEKE approval card: it says a change freeze is in effect, that the plan is untouched and still waiting, and that the window ends in about 42 minutes; beside it the window's name and the rejection code sit as badges. The plan body and the apply button are still in place
The card during a freeze: why it waits and how long is left, in one band.

Central policy package

  • Policies can arrive as one package. It carries rules and windows, versioned and signed.
  • The signing key is yours. It is separate from the license key and not baked into the image.
  • A package with a bad signature is rejected. The version in force stays.
policy package · version 3
The YEKE policy package screen: the identity card of the package in force — version number, how many policies and change-freeze windows it carries, its fingerprint, who installed it and when. Below it an install history table with the same columns for three versions and a button to download each body
The package in force and the install history: who, when, which version.

Terminal session recording

  • Enable per cluster. Terminal recording is off by default.
  • There is no covert recording. The user is told on the terminal's first line.
  • Recordings are stored encrypted and can be downloaded. You choose the player.
  • What it does not do: no inline playback in the browser.
pod terminal · recording on
A YEKE pod terminal: at the very top a band saying this session is being recorded, that everything it prints is stored encrypted and can later be downloaded by an administrator as a replayable file, with the session's id beside it. Below it, the kubectl commands that were run and their output
The terminal's first line when recording is on, as the session starts.

Compliance report

  • Report from existing records. Reports use the audit trail without creating new events.
  • It carries its own integrity proof. The hash chain ends and the event count are inside it.
  • A single-file HTML document. It opens in an air-gapped installation too.
  • The report language is chosen separately. A report is written for whoever reads it.

Setting up the governance items →  ·  Policies →

compliance report · cluster × period
The YEKE compliance report form: cluster selection, the first and last day of the period, a format choice (single-file HTML) and the report's language. Below the form, a note saying the report is independent of the interface language, and a download button
A report is generated for one cluster and one period.
generated report · single file
The generated change report itself, as a single-file document: at the top the cluster, the period, when it was generated and by whom; then the chain summary — event count, the hash of the first and last record, and the range of the trail it covers; below that the operations that were applied, each with who ran it, under which Kubernetes identity, under which policy version, and with whose approval and whose consent
The generated report itself: this is what goes to the auditor.
In the product today

Phase E4

GitOps and process

Manage cluster changes alongside your repo and connect ITSM checks to the approval flow.

Repo reflection and drift

  • Urgent fixes reach the repo too. An approved change is applied to the cluster first, then its YAML counterpart is committed to the tracked branch. The next reconcile applies the updated repo.
  • What will change is visible before approval. The card also shows the repo file and the line.
  • If the branch is protected, the screen says so. If the push is refused, a proposal branch is opened. Until you merge it, the next reconcile can revert the change.
  • Drift shows what slipped through. A change that did not reach the repo shows up as a difference in the drift report, wherever the report can read the scope. Delivery to the cluster stays with your GitOps controller; YEKE does not trigger it.

Measurement scope: the chain was measured end to end against our own self-hosted GitLab CE and Flux; other git providers and Argo CD are outside that measurement. All of the limits →

approval card · repo half
The repo section of a YEKE approval card: below the diff table showing what will change on the cluster, a 'What will change in the repo' heading, a badge saying the repo will be updated, the target branch, a checkbox to mirror the change into the repo, and the path of the file that will change — with the line it is edited from and how many lines go out and come in
The repo half of the approval card: which line of which file will change.

ITSM: the change record at approval time

  • Start from the example integration. ITSM support provides an example hook endpoint and documentation.
  • Validation hooks are part of this item. Since 0.65.0 the hook that asks your own system at plan and approval time is the license's itsm item; notification hooks stay in Community.
  • The answer lands on the card. The change record's number and status show up there.
  • With no record the plan stops. A record outside its window raises the approval bar.

The ITSM example endpoint and the protocol →

approval card · itsm-change
The validation hooks section of a YEKE approval card: on the itsm-change hook's row, an 'elevated' badge, the change record's number, a status showing the record is approved, and the hook's own reason sentence — saying the record is approved but outside its window, so the approval bar was raised. At the bottom of the card, a field asking for the resource's name to be typed in order to approve
The change record inside the card: number, status and the hook's own sentence.
In the product today

Phase E6

Access and Secret management

Decide who sees Secret values in YEKE, and how much of them.

  • Installation-wide Secret display ceiling. Values are shown masked or fully hidden to everyone, owner included; a new value can be written without seeing the old one. Secret display →
  • Per-key Secret access. The permission group does not read Secrets in the cluster; YEKE shows or lets it edit only the keys a rule allows. Rules are written at group level (all Secrets) or per Secret and key. Permission groups →
  • Effective access view. Reads what a user can do in each namespace from the cluster's own authorization checks.
  • Secret versions. Every YEKE write is versioned automatically; a change made outside YEKE is caught on the next YEKE write. A single key or the whole Secret is restored through an approval card, and a deleted Secret can be recreated from its history. Secret versions →

Limit: these items limit viewing through YEKE. Someone who can open a shell in a pod or edit a workload can read the value from inside the container.

Licensing and tiers

An Enterprise license is a signed block of text installed into the product. It is verified offline: no license server, no activation, no periodic check.

  • A license only raises limits. It never takes you below the Community ceilings.
  • Configured controls remain active. Existing dual-approval and change-freeze rules and validation hooks already set up stay enforced after license expiry; new configuration is restricted.
  • Existing records remain readable. Technical guides explain license behavior for each feature.
  • It is not tied to hardware. The license goes to a legal entity, not a machine.

Scope and price are settled in a conversation; this page is not a contract. The split between the tiers is on the pricing page.

license · enterprise
The YEKE license screen: an Enterprise badge, the legal entity the license was issued to, the issue and expiry dates; below them two bars showing clusters and users in use against their ceilings, and the list of feature flags the license unlocks. Further down, the field where a license block is pasted and a button that reverts the installation to Community
The license screen: ceilings, usage and the flags the license unlocks.
sso audit-export ha-postgres retention-archive metrics-retention policy-central dual-approval change-freeze session-recording compliance-reports gitops-mode drift-visibility itsm metrics-alerts secret-display secret-keys effective-access secret-versions

The license screen shows enabled features and capacity usage.

What is still on the roadmap

On the roadmap

One item is on the roadmap: SCIM and SAML (E1 — they were under E6 until 23.09.2026 and moved because they connect the organization's own identity system, the same as SSO). No date is committed. Anomaly detection for monitoring (E5) has been in the product since 0.69.0. The breakdown is in the E1 and E5 boxes on the pricing page.

yeke.io

Install it first, then let's talk.

Try Community in your own environment. Request a demo to evaluate Enterprise features.

Request a demo How the tiers split Install Community