Kafdeck v0.7 — Developer & Streaming Ecosystem Platform

Kafdeck v0.7 — Developer & Streaming Ecosystem Platform

Status: OWNER-AUTHORIZED v0.7 RELEASE NOTES

v0.7 is the owner-authorized release identity assembled by W51–W60 and selected by the governed release manifest. Publication is performed only by the protected-main release workflow after exact-head quality, compatibility, security and supply-chain gates succeed.

Highlights

Schema Registry lifecycle and developer tooling

• Confluent-compatible lifecycle capability truth;
• explicit Karapace-compatible profile;
• explicit Apicurio Unsupported state until a typed adapter is admitted;
• Avro, Protobuf and JSON Schema;
• references, bounded reference graph, deterministic diff and compatibility explanation;
• bounded deterministic mock examples;
• governed registration/compatibility/delete paths.

Multi-profile Kafka Connect

• multiple stable Connect profiles per Kafka cluster;
• legacy default profile compatibility;
• typed read/mutation routes;
• plugin discovery and validation;
• secret-safe configuration handling;
• bounded optional auto-restart with durable attempts/backoff/lifetime/circuit state;
• shared MM2/replication guard.

Controlled data tooling

• CBOR, XML and MessagePack controlled SerDe;
• XML external entity/DTD/resource resolution prohibited;
• governed replay/reprocess/DLQ/cross-topic/cross-cluster forwarding jobs;
• finite budgets, durable checkpoints and no-blind-replay ambiguity semantics;
• deterministic Smart Mock / Data Generator with explicit destination policy and hard volume/rate/time caps.

Streaming ecosystem

• bounded single-statement read-only ksqlDB SELECT tooling;
• no DDL/DML/persistent query creation;
• registered Kafka Streams application/topology/state-store evidence;
• lineage with Observed/Inferred edge kinds, provenance, confidence and stale truth;
• inferred lineage never satisfies authorization.

Developer/operator UX

• keyboard-first Command Palette with Ctrl/Cmd+K;
• registered typed navigation only;
• integrated topic/catalog/schema/Connect/data-job/generator/ksql/Streams/lineage surfaces;
• unified explicit states for Denied, Unsupported, Blocked, Partial, Stale, Unavailable, Unknown, approval and unresolved external effects;
• focus containment/restoration and reduced-motion support.

Browser and air-gap security

• deployment access token is memory-only after URL-fragment bootstrap and immediate URL scrub;
• no secret/payload local/session storage;
• no runtime CDN;
• locally bundled Tabler/frontend assets;
• local OpenAPI contract.

Compatibility posture

Kafka broker validation retains Kafka 4.3.1, 4.2.1 and 4.1.2 as Tier 1 and Kafka 3.9.2 as Tier 2.

Ecosystem compatibility is capability- and evidence-driven. Kafdeck does not claim blanket vendor-version support merely because an endpoint is protocol compatible. See docs/architecture/v0.7-provider-capabilities.md.

Publication integrity

Owner publication authorization was granted under Issue #203 on 2026-09-27. The release is still fail-closed: the protected-main workflow must validate the exact source revision, full Kafka compatibility matrix, SBOM and High/Critical vulnerability gate before it may create the immutable v0.7 tag, GitHub Release, signed/provenanced OCI digest and final GHCR tags.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:2e089bfe4788d93e7f9b5d03fac117001daccd06c244f1017648d5ccf57535c8

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA 23b3777461649f53f602ebf49c1ffd3607b546f7.

Kafdeck v0.6 — Fleet Operations and Secure Remote UI

Kafdeck v0.6 — Fleet Operations and Secure Remote UI

Kafdeck v0.6 is the active release line for the project.

This release advances Kafdeck from the v0.5 governed administration baseline toward a capability-driven Kafka fleet control plane. It also completes two operator-facing deployment improvements: safe remote/multi-address web binding and a Tabler-based branded dashboard using the Kafdeck logo.

Highlights

Remote and multi-address deployment

Kafdeck now supports the preferred Kafdeck:Deployment:ListenUrls[] setting while retaining backward compatibility with the legacy single ListenUrl.

Examples:

{
  "Kafdeck": {
    "Deployment": {
      "ListenUrls": [
        "http://0.0.0.0:8080"
      ],
      "AccessMode": "Token",
      "AccessToken": "env:KAFDECK_DEPLOYMENT_TOKEN"
    }
  }
}

or multiple explicit endpoints:

{
  "Kafdeck": {
    "Deployment": {
      "ListenUrls": [
        "http://127.0.0.1:8080",
        "http://192.168.10.20:8080"
      ],
      "AccessMode": "Token",
      "AccessToken": "env:KAFDECK_DEPLOYMENT_TOKEN"
    }
  }
}

Local mode remains loopback-only. Remote or wildcard binding requires the existing Token or OIDC boundary. Non-loopback OIDC bindings require HTTPS. Host filtering is derived from the validated listen endpoints.

Tabler operator dashboard and Kafdeck branding

The React operator UI now uses locally pinned @tabler/core 1.5.1 assets with no runtime CDN dependency. The existing Kafdeck logo is used in the application header and browser icon.

The shell includes responsive navigation, cards, tables, forms, alerts and badges, system light/dark behavior, reduced-motion support, and the existing blue/orange Kafdeck brand treatment.

Fleet capability truth

v0.6 adds a read-only capability surface:

GET /api/v1/fleet/capabilities
GET /api/v1/openapi/v0.6.json

The UI also includes a Fleet Operations — v0.6 view. Capability states are explicit: Supported, Unsupported, Blocked, Unconfigured, or Unknown. Kafdeck does not convert an unavailable provider API into a CLI, REST, reflection, raw-protocol, or sidecar escape path.

Fleet work admitted in v0.6

The release contains the governed domain/provider foundations for:

• closed compound fleet authorization and risk contracts;
• durable fleet progress, conflict obligations, fencing and recovery primitives;
• ACL provider/domain contracts;
• SCRAM provider/domain contracts with write-only credential material boundaries;
• allowlisted typed dynamic broker/default configuration;
• finite cross-cluster transfer plans, physical-cluster conflict identity, exact destination-partition production, durable no-replay dispatch checkpoints, and bounded source-range reading;
• shared Kafka Connect guards that prevent MirrorMaker activation from bypassing Kafdeck governance.

These foundations are not all public mutation surfaces. The capability catalog reports production activation truth separately.

Explicit v0.6 capability limitations

The following are intentionally not advertised as active mutation capabilities in v0.6:

Capability	v0.6 state	Reason
ACL administration	Blocked	typed provider/domain work is admitted, but the production v0.6 API/runtime does not register the W42 mutation handler surface
SCRAM administration	Blocked	typed provider/domain work is admitted, but the production v0.6 API/runtime does not register the W43 mutation handler surface
Allowlisted dynamic configuration	Blocked	typed provider/domain work is admitted, but the production v0.6 API/runtime does not register the W44 mutation handler surface
Client quotas	Unsupported	pinned Confluent.Kafka 2.15.1 exposes no typed ClientQuotas describe/alter API
Preferred leader election	Blocked	the provider primitive exists, but the complete W45 production safety/readback surface is not activated
Partition reassignment	Unsupported	pinned Confluent.Kafka 2.15.1 exposes no typed reassignment submit/list API
Replication-factor changes	Unsupported	the admitted path depends on typed reassignment
Reassignment throttles	Blocked	not exposed independently from the unavailable reassignment lifecycle
Broker maintenance	Blocked	required typed evacuation/reassignment/unregister lifecycle is incomplete
Log-directory maintenance	Unsupported	no complete admitted typed pinned-client lifecycle exists
Finite cluster transfer	Blocked	durable planning/dispatch/source-range foundations exist, but the long-running current-identity orchestration path is not activated
Managed MirrorMaker 2 activation	Blocked	standard MM2 cannot enforce Kafdeck lifetime byte/record/rate/revocation guarantees

Blocked and Unsupported are intentional release states, not hidden failures.

Kafka compatibility baseline

The release validation matrix retains:

• Kafka 4.3.1 — Tier 1
• Kafka 4.2.1 — Tier 1
• Kafka 4.1.2 — Tier 1
• Kafka 3.9.2 — Tier 2

Support remains capability-driven. A version appearing in the matrix does not imply every v0.6 fleet mutation is available on that version.

Upgrade from v0.5.1

• Existing ListenUrl deployments remain accepted.
• ListenUrls[] is the preferred form for new deployments.
• The default application configuration remains loopback-only.
• Existing v0.5 mutation and persistence identities are retained; v0.6 does not reinterpret an unresolved v0.5 mutation as safe to replay.
• Existing operator authorization and antiforgery requirements remain in force.
• Tabler assets are included in the built frontend; no Internet connection is required at runtime.

Review the deployment configuration before exposing Kafdeck on a management network. Do not expose development Kafka PLAINTEXT listeners to untrusted networks.

Supply-chain release

The governed publication workflow builds the release candidate from the exact protected-main SHA, validates backend/frontend tests and the Kafka compatibility matrix, generates an SPDX SBOM, scans the exact OCI candidate for High/Critical vulnerabilities, signs the approved digest, and publishes immutable release tags.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:cc0913c8421552c84888911779f79a09f25614901430fd6e58be2e8cadfce818

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA 63670ec06d039e13c096b2d08828ebfe228f979c.

Kafdeck v0.5.1 — Release Integrity Corrections

Kafdeck v0.5.1 — Release Integrity Corrections

Kafdeck v0.5.1 is a scope-neutral corrective patch for the v0.5 release line. It publishes the already-reviewed release-integrity fixes under a new immutable identity while preserving the original v0.5 tag, GitHub Release and OCI artifacts unchanged.

Corrections

• backend assembly/package identity is aligned with the governed release manifest at 0.5.1,
• frontend package and lockfile identity are aligned at 0.5.1,
• /api/v1/system/info now reports controlledMutations only when mutation mode is actually enabled and otherwise reports readOnly,
• README/roadmap release-state wording is reconciled with the released v0.5 capability set,
• release-identity regression coverage verifies manifest/package consistency and preserves prerelease suffixes.

Scope and safety

This patch adds no new mutation class, provider surface or product scope. All v0.5 safety and governance invariants remain unchanged:

• read access does not imply mutation permission,
• mutation mode remains opt-in and fail-closed,
• server-owned risk floors and independent approval for CRITICAL operations remain enforced,
• durable mutation state/idempotency/claims remain mandatory,
• ambiguous potentially-applied outcomes remain ExecutionUnknown unless bounded verification proves a stronger state,
• raw Kafka payloads and secrets are not durably staged by default,
• no generic Kafka CLI/AdminClient/provider REST proxy or arbitrary server-side code execution is introduced.

Publication integrity

The published v0.5 identity remains immutable and is not moved, replaced or republished. Corrected artifacts are published only as v0.5.1 from the exact protected-main source revision admitted for this patch.

Publication remains gated by the repository release workflow: exact-revision quality checks, Kafka compatibility, SBOM generation, High/Critical vulnerability scanning, keyless signing, immutable OCI digest promotion and GitHub Release creation must all complete successfully.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:3204fb92fa800a40c246ee94d279dfb7557cd211f6de7157ebbad8b223da0290

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA e5de0ec142d5dd06ef52f59718c60c3109d1070a.

Kafdeck v0.5 — Safe Administration & Controlled Mutations

Kafdeck v0.5 — Safe Administration & Controlled Mutations

Kafdeck v0.5 adds governed administrative mutation workflows on top of the read-only foundations from v0.4. Mutation execution is explicit, bounded, durable, authorization-aware, risk-classified, previewed before execution, independently approved where required, and designed to preserve truthful outcomes when provider effects are ambiguous.

Included capabilities

• durable mutation operation state, idempotency, resource claims and recovery semantics,
• server-owned risk floors with independent approval for CRITICAL operations,
• stale-preview and current-state precondition revalidation,
• governed topic administration,
• bounded single/batch/template-assisted Kafka record production,
• consumer group and offset administration,
• Schema Registry register/config/delete workflows,
• Kafka Connect create/update/delete/pause/resume/restart workflows,
• controlled DeleteRecords purge with explicit partition/offset targets,
• REST/OpenAPI and operator UI workflows for preview, confirm, approve, reject, cancel and status,
• explicit ExecutionUnknown handling for potentially-applied ambiguous outcomes,
• SQLite standalone and PostgreSQL HA persistence paths,
• upgrade, backup/restore, rollback and operator guidance.

Safety invariants

v0.5 deliberately does not introduce a broad admin bypass or generic provider command surface.

• read permissions do not imply mutation permissions,
• raw Kafka payloads and secrets are not durably staged by default,
• record-production execution material is ephemeral and digest-bound to preview,
• no blind retry occurs after a potentially applied dispatch,
• ambiguous provider outcomes remain ExecutionUnknown unless bounded verification supports a stronger state,
• no arbitrary Kafka producer configuration passthrough,
• no generic Kafka CLI/AdminClient or provider REST proxy,
• no arbitrary JavaScript, SQL, shell or serializer/runtime execution,
• destructive purge requires explicit bounded targets and CRITICAL governance where applicable.

Governed mutation areas

Topics

Create topic, allowlisted configuration changes, partition increases and topic deletion use typed provider ports, finite materialized targets, current-state fingerprints and verification readback.

Record production

Single, batch and template-assisted production enforce record/byte/header ceilings, exact-topic record.produce authorization, optional schema validation, HMAC-bound ephemeral execution material, broker acknowledgement evidence and payload-leakage protections.

Consumer groups and offsets

Offset resolution, reset/alter/delete operations preserve group-state preconditions, explicit target previews and post-operation verification.

Schema Registry

Typed fixed-route mutations cover schema registration/new versions, compatibility configuration and governed deletion semantics without exposing a generic registry write proxy.

Kafka Connect

Connector lifecycle mutations use a fixed-route adapter, secret-safe diffs, bounded request/response handling, redirect/origin restrictions and typed operations.

Controlled purge

DeleteRecords is restricted to explicit partition/offset targets or bounded timestamp resolution into frozen offsets. Whole-topic wildcard purge is not provided.

Compatibility and readiness

Kafka behavior is validated against the governed matrix:

Tier 1:

• Apache Kafka 4.3.1
• Apache Kafka 4.2.1
• Apache Kafka 4.1.2

Tier 2:

• Apache Kafka 3.9.2

W40 readiness also reconciled security/threat-model coverage, Schema Registry and Kafka Connect mutation fixtures, SQLite/PostgreSQL persistence and recovery, ambiguous-outcome fault handling, boundedness evidence, regression benchmarks and operator documentation.

Upgrade and operation

Review the v0.5 operator and upgrade guidance before enabling mutation features. Mutation runtime activation remains fail-closed unless deployment prerequisites, persistence and authorization integration requirements are satisfied.

Release governance

Implementation W32-W40 was governed-admitted through protected main, culminating in PR #141 and protected-main commit 9441697248a09694b54d84b390725511f138dcfd.

Ammar explicitly approved the v0.5 release decision on 2026-09-23. Publication is armed only by promotion of the v0.5 identity through .github/release/release.json. The protected-main publication workflow must complete its exact-revision quality, Kafka compatibility, SBOM, High/Critical vulnerability scan, keyless signing, immutable OCI promotion and GitHub Release steps before publication is considered complete.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:37196487ae5869144bdde312c92aafdd300c7f411473077b901ca368fabcfcab

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA 0901b6b7c4c8c580268e05d1b7c04ec591d2e5cf.

Kafdeck v0.4 — Consumers, Schemas & Ecosystem Read Views

Kafdeck v0.4 — Consumers, Schemas & Ecosystem Read Views

Kafdeck v0.4 expands the read-only control plane with consumer-group diagnostics, Schema Registry exploration, and bounded ecosystem read views while preserving the released v0.3 data-access boundary and no-mutation posture.

Included capabilities

• separately authorized consumer.read, schema.read, connect.read, ksql.read, and catalog.read,
• consumer group state, members and assignments,
• committed offsets, end offsets, per-partition lag and aggregate lag,
• explicit missing/out-of-range/unauthorized/partial lag states,
• evidence-based consumer diagnostics with explicit unavailable metrics/history,
• Schema Registry subjects, versions, references and schema detail,
• bounded local schema diff,
• read-only compatibility-mode inspection,
• Kafka Connect worker, connector and task status,
• fail-closed connector configuration projection,
• bounded/redacted connector task traces,
• GET-only ksqlDB info/health discovery,
• explicit unsupported state where ksqlDB metadata would require statement execution,
• configuration-owned topic catalog metadata foundations,
• REST/OpenAPI/operator UI parity.

Security posture

v0.4 adds no mutation surface:

• no Kafka produce/replay,
• no consumer offset commit/reset/shift/delete,
• no topic/configuration mutation,
• no Schema Registry mutation,
• no Connect create/update/delete/pause/resume/restart,
• no ksqlDB statement/query execution,
• no generic upstream HTTP proxy,
• no arbitrary server-side JavaScript,
• no masking bypass.

All new read permissions remain independent from record.read and record.export.

External ecosystem endpoints are deployment-configured, bounded, cancellable, redirect-restricted and isolated by separate concurrency bulkheads.

Consumer truthfulness rules

• an offset beyond the observed log end is out-of-range, not zero lag,
• missing committed offsets are explicit,
• partial Kafka authorization remains explicit,
• unknown is never represented as zero,
• metrics/history are unavailable unless an explicit provider supplies trustworthy evidence,
• current observation is not labeled historical analysis.

Schema Registry posture

The registry explorer uses read-only GET operations only.

Compatibility provenance is determined by subject-specific configuration first and global fallback only when the subject has no override.

Schema diff executes locally under input-size/line bounds.

Kafka Connect posture

Connector configuration is fail-closed: only a small explicit allowlist of operational fields may expose values; all other plugin-defined values are redacted.

Task traces are bounded and credential-like values are redacted.

ksqlDB posture

v0.4 supports server info/health through genuine read-only endpoints.

Kafdeck does not execute SHOW, DESCRIBE, arbitrary SQL, or metadata statements. When metadata discovery requires statement execution, the capability is reported unsupported.

Compatibility

Kafka consumer-group behavior is validated against the governed matrix:

Tier 1:

• Apache Kafka 4.3.1
• Apache Kafka 4.2.1
• Apache Kafka 4.1.2

Tier 2:

• Apache Kafka 3.9.2

Schema Registry, Connect and ksqlDB claims are capability/profile evidence, not blanket Kafka-provider equivalence.

Known limitations

• no mandatory durable consumer metrics/history provider,
• no historical rebalance analysis without an explicit history provider,
• one optional Connect profile and one optional ksqlDB profile per Kafka cluster,
• ksqlDB stream/table discovery is unsupported when statement execution is required,
• topic catalog metadata is configuration-owned and descriptive only,
• no ecosystem mutation.

Operator documentation

• docs/operator/v0.4-read-views-guide.md
• docs/operator/v0.4-upgrade-guide.md

Release governance

The exact technical candidate a94b3baa415f32b7b8420c4bc398f405fa674709 passed the required quality, security, compatibility, benchmark, review-thread, supply-chain and CODEOWNER gates and was admitted through PR #118 as protected-main commit b05b61f1835effcee78a7aef4d6eb481faba8915.

Ammar explicitly approved the v0.4 Release Decision on 2026-09-21. Publication is armed only through a separate governed promotion of the approved v0.4 identity into .github/release/release.json; the protected-main publication source must still complete the exact release workflow before tag/image/GitHub Release publication is considered complete.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:8183ced585bd6eb73bf280f4ded5751e2ffc9370b1e170e0b9074a3acc9e2ed1

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA e22426026d4f03f675df703773ca072ed7ea0f03.

Kafdeck v0.3 — Safe Data Explorer + Server-Side Masking

Kafdeck v0.3 — Safe Data Explorer + Server-Side Masking

Kafdeck v0.3 introduces bounded Kafka record inspection under the v0.2 Operator Identity/RBAC boundary while preserving Kafdeck's no-mutation posture.

Included capabilities

• separately authorized record.read and record.export,
• explicit topic/partition record browsing,
• earliest/latest/offset/timestamp navigation,
• bounded previous-page reconstruction,
• bounded live tail,
• key/value/header inspection,
• UTF-8 text, structured JSON and safe binary/hex projection,
• read-only Schema Registry-assisted Avro, Protobuf and JSON Schema decoding,
• bounded key/header/range/regex/CEL/jq-style filtering,
• authoritative server-side masking/redaction before browser/API/export,
• fail-closed behavior when mandatory structured masking cannot be safely applied,
• bounded JSON, NDJSON and CSV export,
• explicit record/byte/time/rate/concurrency budgets,
• cancellation and per-cluster/global record-read isolation,
• record-read/export security audit events,
• REST/OpenAPI and operator UI parity,
• benchmark/readiness evidence.

Security posture

• metadata permissions do not imply record access,
• export requires a separate permission,
• no masking bypass permission exists in v0.3,
• payloads are not persisted/indexed by default,
• clear record values are excluded from logs, traces, audit records and safe errors,
• Schema Registry access is read-only and used only for decoding,
• no arbitrary server-side JavaScript is executed,
• no general-purpose SQL stream engine is introduced.

Kafka safety posture

v0.3 remains non-mutating toward Kafka:

• no record production or replay,
• no topic/configuration mutation,
• no consumer-group offset mutation,
• no offset commit,
• no durable consumer subscription,
• no unbounded whole-topic scan.

Record reads use bounded explicit partition/range semantics with cancellation, deadlines and isolated bulkheads.

Compatibility

The governed release workflow validates the accepted compatibility matrix on the exact release source:

Tier 1:

• Apache Kafka 4.3.1
• Apache Kafka 4.2.1
• Apache Kafka 4.1.2

Tier 2:

• Apache Kafka 3.9.2

Performance evidence

The final W24 technical candidate recorded bounded in-process release microbenchmarks:

• structured filter: 20,000 operations / 83.371 ms / 239,890.99 ops/s,
• structured masking: 20,000 operations / 399.056 ms / 50,118.28 ops/s.

These measurements are implementation-level release evidence only. They are not Kafka end-to-end throughput figures or a public SLA.

Known limitations

• payload search is bounded scan, not persistent indexing,
• Schema Registry support in v0.3 is decode-only rather than a full subjects/versions explorer,
• live tail is bounded and non-durable,
• record payloads are not retained by Kafdeck,
• full Consumer Group/Lag read views remain deferred,
• Kafka mutations remain deferred.

Operator documentation

Record access, masking and export guidance is in docs/operator/v0.3-record-access-masking-guide.md.

Upgrade guidance from v0.2 is in docs/operator/v0.3-upgrade-guide.md.

Release evidence

Publication requires protected-main admission of the cumulative v0.3 source, exact-revision quality and Kafka compatibility gates, supply-chain evidence, High/Critical vulnerability scanning, keyless signing, immutable OCI digest promotion, and publication of tag v0.3 on the exact governed release SHA.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:ac5178a7d6f1a08cb303979f4c6de66aa711b220468c193f3d16d1a91483628e

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA fb2eb253dfa2b51d28c45e15f7d29ea1100fef85.

Kafdeck v0.2 — Operator Identity/RBAC

Kafdeck v0.2 — Operator Identity/RBAC Release Notes

Kafdeck v0.2 adds governed operator identity and authorization while preserving the read-only Kafka boundary established in v0.1.

Included capabilities

• OIDC Authorization Code + PKCE operator sign-in with server-side sessions,
• explicit Local, Token, and OIDC access modes with no OIDC-to-token fallback,
• immutable, default-deny RBAC policy evaluation,
• subject and external-group role bindings,
• action-, cluster-, and resource-scoped authorization,
• backend-authoritative API enforcement with corresponding operator UI behavior,
• structured security audit events for authentication, authorization denials, sensitive configuration reads, and legacy deployment-token boundary events,
• upgrade and rollback guidance for existing v0.1 deployments.

Security posture

• no Kafka mutation endpoint or UI control,
• no record production/consumption or payload browser,
• deployment tokens are not treated as operator identity,
• unbound identities and ungranted actions fail closed,
• OIDC tokens, session cookies, deployment tokens, and Kafka credentials are excluded from API/log/audit output,
• Kafka ACL denial remains distinct from Kafdeck RBAC denial,
• non-loopback OIDC deployments require HTTPS and normal platform trust validation; TLS verification cannot be disabled.

Compatibility

v0.2 preserves the v0.1 Local and Token deployment modes. Kafka access remains metadata/configuration read-only. The governed release workflow re-runs the accepted Kafka compatibility matrix against the exact release source revision.

Known limitations

• application sessions are intentionally invalidated by restart,
• durable shared session state is not part of v0.2,
• durable audit-history storage is not part of v0.2,
• identity-provider reachability and private-CA trust remain deployment responsibilities,
• v0.2 does not introduce Kafka mutation or payload access.

Operator documentation

OIDC/RBAC deployment guidance is in docs/operator/v0.2-oidc-rbac-guide.md. Upgrade and rollback guidance is in docs/operator/v0.2-upgrade-guide.md.

Release evidence

Publication requires the approved release delta on protected main, exact-revision quality and Kafka compatibility gates, independent review, supply-chain evidence, immutable OCI digest promotion, keyless signing, and publication of tag v0.2 on the exact release SHA.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:759ca8e8b3d5491941dcfb1de8b76b7aeffd01a275204238e541d09e5de186f5

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA 9fef5736ddd5c40854d12ad89afd9489987e808f.

Kafdeck v0.1 — Cluster Explorer

Kafdeck v0.1 — Cluster Explorer Release Notes

Kafdeck v0.1 is the first release candidate of the read-only, multi-cluster Cluster Explorer.

Included capabilities

• configured multi-cluster discovery with isolated Kafka clients and caches,
• cluster, controller and broker visibility with explainable health,
• searchable topic exploration with bounded pagination,
• partition leader/replica/ISR and anomaly visibility,
• on-demand broker/topic configuration reads subject to Kafka authorization,
• explicit fresh/stale/partial/denied/unavailable observation states,
• React operator UI and versioned /api/v1 HTTP surface,
• single non-root OCI image for UI + API,
• local-first deployment with token-gated non-loopback access,
• TLS, mTLS, SASL PLAIN and SCRAM connection support within the accepted matrix.

Kafka compatibility baseline

Tier 1:

• Apache Kafka 4.3.1
• Apache Kafka 4.2.1
• Apache Kafka 4.1.2

Tier 2:

• Apache Kafka 3.9.2

The release gate re-runs the compatibility/security matrix against the exact release source revision.

Security and supply chain

• no Kafka mutation endpoint or UI control,
• no Kafka payload browsing,
• no durable persistence of Kafka passwords/private-key passwords,
• secret references for deployment and Kafka credentials,
• non-loopback access fails closed without the deployment token,
• exact-digest SBOM and High/Critical vulnerability scan,
• locked dependency restore,
• keyless Sigstore/cosign signing of the published OCI digest,
• SHA-pinned third-party GitHub Actions.

The release-specific threat-model delta is documented in docs/security/v0.1-release-threat-model-delta.md.

Known limitations

• the deployment token is a deployment boundary, not human identity/RBAC,
• v0.1 is intentionally read-only,
• no topic/group/ACL/broker mutation is supported,
• no record production/consumption or payload browser is included,
• operational health reflects bounded Kafka admin-read observations, not end-to-end application health,
• supported Kafka versions are limited to the documented release matrix.

Operator documentation

Deployment, configuration, air-gapped operation, authentication bootstrap, troubleshooting and security guidance are in docs/operator/v0.1-operator-guide.md.

Release evidence

Publication requires the accepted release commit on main, all applicable exact-revision gates green, independent review of this final release delta, active Phase 0 repository controls, and successful tagged release supply-chain evidence.

Immutable OCI image

ghcr.io/araditc/kafdeck@sha256:ef82b45c5b74e2a0346c9226f9aae6c19d898f1acc231620088b04e2b74ab3ae

SBOM and vulnerability-scan evidence are retained by the release workflow for source SHA 137142bc3733fe3354e2941b8c09ce7d63326741.