diff --git a/docs/v0.13.0/_files/_assets/attributes.adoc b/docs/v0.13.0/_files/_assets/attributes.adoc
deleted file mode 100644
index 48f00def..00000000
--- a/docs/v0.13.0/_files/_assets/attributes.adoc
+++ /dev/null
@@ -1,88 +0,0 @@
-// AsciiDoc settings
-:data-uri!:
-:doctype: book
-:experimental:
-:idprefix:
-:imagesdir: images
-:numbered:
-:sectanchors!:
-:sectnums:
-:source-highlighter: highlight.js
-:toc: left
-:linkattrs:
-:toclevels: 2
-:icons: font
-
-//Latest version
-:KroxyliciousVersion: 0.13
-:gitRef: releases/tag/v0.13.0
-:ApicurioVersion: 2.6.x
-:KubernetesVersionMinimum: 1.31
-:OpenShiftVersionMinimum: 4.18
-
-:OperatorDownloadUrl: https://github.com/kroxylicious/kroxylicious/releases[GitHub releases page^]
-:OperatorAssetZipFileName: kroxylicious-operator-{KroxyliciousVersion}.zip
-:OperatorAssetTgzFileName: kroxylicious-operator-{KroxyliciousVersion}.tar.gz
-
-//Proxy links
-:github: https://github.com/kroxylicious/kroxylicious
-:github-releases: https://github.com/kroxylicious/kroxylicious/{gitRef}
-:github-issues: https://github.com/kroxylicious/kroxylicious/issues
-:api-javadoc: https://javadoc.io/doc/io.kroxylicious/kroxylicious-api/{KroxyliciousVersion}
-:kms-api-javadoc: https://javadoc.io/doc/io.kroxylicious/kroxylicious-kms/{KroxyliciousVersion}
-:encryption-api-javadoc: https://javadoc.io/doc/io.kroxylicious/kroxylicious-encryption/{KroxyliciousVersion}
-:start-script: https://github.com/kroxylicious/kroxylicious/blob/{gitRef}/kroxylicious-app/src/assembly/kroxylicious-start.sh
-
-//Kubernetes links
-:KubeTools: link:https://kubernetes.io/docs/tasks/tools/[Install Tools^]
-
-//Kafka links
-:ApacheKafkaSite: https://kafka.apache.org[Apache Kafka website^]
-:kafka-protocol: https://kafka.apache.org/protocol.html
-
-//java links
-:java-17-javadoc: https://docs.oracle.com/en/java/javase/17/docs/api
-:java-17-specs: https://docs.oracle.com/en/java/javase/17/docs/specs
-:tlsProtocolNames: https://docs.oracle.com/en/java/javase/17/docs/specs/security/standard-names.html#sslcontext-algorithms
-:cipherSuiteNames: https://docs.oracle.com/en/java/javase/21/docs/specs/security/standard-names.html#jsse-cipher-suite-names
-
-//Vault links
-:hashicorp-vault: https://developer.hashicorp.com/vault
-
-//Fortanix DSM links
-:fortanix-dsm: https://www.fortanix.com/platform/data-security-manager
-:fortanix-support: https://support.fortanix.com/
-
-//AWS links
-:aws: https://docs.aws.amazon.com/
-
-// Apicurio links
-:apicurio-docs: https://www.apicur.io/registry/docs/apicurio-registry/{ApicurioVersion}/
-
-// Kubernetes links
-:KubernetesSite: https://kubernetes.io/
-:OperatorPattern: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
-
-// Java Operator SDK links
-:josdk: https://javaoperatorsdk.io/
-:josdk-metrics: https://github.com/operator-framework/java-operator-sdk/blob/v5.0.4/docs/content/en/docs/features/_index.md#operator-sdk-metrics
-
-// Conditional inclusion flags
-// (note: we control optional inclusion with ifdefs/ifndefs directives, so the value of the attribute is irrelevant)
-:include-fortanix-dsm-kms: 1
-:include-aws-kms-service-config-identity-ec2-metadata: 1
-:include-platform-bare-metal: 1
-// We're not ready to enable OLM yet
-//:include-olm: 1
-//:OpenShiftOnly: 1
-
-//API stability markers.
-:unstable-api-version: denoted by a major version 0
-:stable-api-version: version 1.0.0
-
-// We have a development document (docs/index.adoc) that sits one level higher than the guides, so we need a way to override DocRoot.
-ifndef::DocRoot[:DocRoot: ..]
-:ProxyGuide: link:{DocRoot}/kroxylicious-proxy/[Kroxylicious Proxy guide]
-:RecordEncryptionGuide: link:{DocRoot}/record-encryption-guide/[Kroxylicious Record Encryption guide]
-:DeveloperGuide: link:{DocRoot}/developer-guide/[Kroxylicious Developer guide]
-:OperatorGuide: link:{DocRoot}/kroxylicious-operator/[Kroxylicious Operator for Kubernetes guide]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/_assets/monitoring-message-counters.excalidraw b/docs/v0.13.0/_files/_assets/monitoring-message-counters.excalidraw
deleted file mode 100644
index a6ad3575..00000000
--- a/docs/v0.13.0/_files/_assets/monitoring-message-counters.excalidraw
+++ /dev/null
@@ -1,3316 +0,0 @@
-{
- "type": "excalidraw",
- "version": 2,
- "source": "https://excalidraw.com",
- "elements": [
- {
- "id": "SRQMmmFIEgEwl3S-nZqKz",
- "type": "rectangle",
- "x": 409.7805480957031,
- "y": 372.8552551269531,
- "width": 111.7470703125,
- "height": 74.5086669921875,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2n",
- "roundness": {
- "type": 3
- },
- "seed": 844550782,
- "version": 238,
- "versionNonce": 947390974,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "Gku3fr140YZ8yPLn4InXq"
- }
- ],
- "updated": 1749631423989,
- "link": null,
- "locked": false
- },
- {
- "id": "Gku3fr140YZ8yPLn4InXq",
- "type": "text",
- "x": 438.20410919189453,
- "y": 385.1095886230469,
- "width": 54.89994812011719,
- "height": 50,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2nG",
- "roundness": null,
- "seed": 1943575102,
- "version": 78,
- "versionNonce": 1116681807,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639891496,
- "link": null,
- "locked": false,
- "text": "Kafka\nClient",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "SRQMmmFIEgEwl3S-nZqKz",
- "originalText": "Kafka Client",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "A7prcJN5rRODipPEZD1RS",
- "type": "rectangle",
- "x": 680.0881723257212,
- "y": 240.61813354492188,
- "width": 691.3812866210938,
- "height": 329.60306959885816,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2o",
- "roundness": {
- "type": 3
- },
- "seed": 2146802594,
- "version": 158,
- "versionNonce": 34534991,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639802653,
- "link": null,
- "locked": false
- },
- {
- "id": "77p-V-i5WNvCKPyz7zZNN",
- "type": "rectangle",
- "x": 1511.81201171875,
- "y": 289.68829345703125,
- "width": 111.7470703125,
- "height": 80.46417236328128,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2p",
- "roundness": {
- "type": 3
- },
- "seed": 592573118,
- "version": 350,
- "versionNonce": 1856508222,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "JNne8hhjrdeQ67mm8iXQn"
- }
- ],
- "updated": 1749631540289,
- "link": null,
- "locked": false
- },
- {
- "id": "JNne8hhjrdeQ67mm8iXQn",
- "type": "text",
- "x": 1535.1355743408203,
- "y": 304.9203796386719,
- "width": 65.09994506835938,
- "height": 50,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2pV",
- "roundness": null,
- "seed": 906500222,
- "version": 64,
- "versionNonce": 1011824257,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639890568,
- "link": null,
- "locked": false,
- "text": "Kafka\nBroker",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "77p-V-i5WNvCKPyz7zZNN",
- "originalText": "Kafka Broker",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "YYehkpK24kcUvHubWkjsE",
- "type": "rectangle",
- "x": 815.0162658691406,
- "y": 311.45068359375,
- "width": 414.7518920898437,
- "height": 203.06689453125,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2t",
- "roundness": {
- "type": 3
- },
- "seed": 400934590,
- "version": 539,
- "versionNonce": 1015456290,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "heTgse6jhcXGXoaMs-Kzw",
- "type": "arrow"
- },
- {
- "id": "d4KuteymFgnAw_3DVPMbP",
- "type": "arrow"
- }
- ],
- "updated": 1749632620954,
- "link": null,
- "locked": false
- },
- {
- "id": "RZk9AmIHMmuP-bsrKbPGM",
- "type": "rectangle",
- "x": 837.6319274902344,
- "y": 332.22393798828125,
- "width": 106.73602294921879,
- "height": 165.39605712890622,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2v",
- "roundness": {
- "type": 3
- },
- "seed": 434562338,
- "version": 740,
- "versionNonce": 584133090,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "YPLEfMEN-45G06Tqb2OLh"
- }
- ],
- "updated": 1749632611357,
- "link": null,
- "locked": false
- },
- {
- "id": "YPLEfMEN-45G06Tqb2OLh",
- "type": "text",
- "x": 856.4099655151367,
- "y": 402.4219665527344,
- "width": 69.17994689941406,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2vG",
- "roundness": null,
- "seed": 777392254,
- "version": 54,
- "versionNonce": 2090180002,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749632611357,
- "link": null,
- "locked": false,
- "text": "Filter 1",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "RZk9AmIHMmuP-bsrKbPGM",
- "originalText": "Filter 1",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "XIwNJahV5FTfaX3WOCHVS",
- "type": "rectangle",
- "x": 963.1584777832031,
- "y": 330.0955810546875,
- "width": 106.73602294921879,
- "height": 165.39605712890622,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2w",
- "roundness": {
- "type": 3
- },
- "seed": 1345072098,
- "version": 828,
- "versionNonce": 1427478882,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "5xqpUac4RR2kw3hRirmoa"
- }
- ],
- "updated": 1749632611357,
- "link": null,
- "locked": false
- },
- {
- "id": "5xqpUac4RR2kw3hRirmoa",
- "type": "text",
- "x": 979.2065124511719,
- "y": 400.2936096191406,
- "width": 74.63995361328125,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2wV",
- "roundness": null,
- "seed": 1756740194,
- "version": 52,
- "versionNonce": 1537219874,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749632611357,
- "link": null,
- "locked": false,
- "text": "Filter 2",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "XIwNJahV5FTfaX3WOCHVS",
- "originalText": "Filter 2",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "SbIwxLw0ycweXX5zQ9BVJ",
- "type": "rectangle",
- "x": 1089.4690246582031,
- "y": 328.5655517578125,
- "width": 106.73602294921879,
- "height": 165.39605712890622,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2z",
- "roundness": {
- "type": 3
- },
- "seed": 1673154594,
- "version": 922,
- "versionNonce": 2107910370,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "vKf1cjfcjM0568RPVkRcG"
- }
- ],
- "updated": 1749632611357,
- "link": null,
- "locked": false
- },
- {
- "id": "vKf1cjfcjM0568RPVkRcG",
- "type": "text",
- "x": 1106.4370651245117,
- "y": 398.7635803222656,
- "width": 72.79994201660156,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b2zV",
- "roundness": null,
- "seed": 1509652770,
- "version": 50,
- "versionNonce": 582007970,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749632611357,
- "link": null,
- "locked": false,
- "text": "Filter 3",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "SbIwxLw0ycweXX5zQ9BVJ",
- "originalText": "Filter 3",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "31YrT48LZ9HssKUpUQIKp",
- "type": "text",
- "x": 544.2095806415264,
- "y": 185.80068030724158,
- "width": 347.48773193359375,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b31",
- "roundness": null,
- "seed": 474774462,
- "version": 324,
- "versionNonce": 507551929,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "q2Huaio8Kx2KPfx91UdrC",
- "type": "arrow"
- }
- ],
- "updated": 1749921511226,
- "link": null,
- "locked": false,
- "text": "kroxylicious_client_to_proxy_request_total\nkroxylicious_client_to_proxy_request_size_bytes",
- "fontSize": 16,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "kroxylicious_client_to_proxy_request_total\nkroxylicious_client_to_proxy_request_size_bytes",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "q2Huaio8Kx2KPfx91UdrC",
- "type": "arrow",
- "x": 668.2661021639458,
- "y": 238.47533240685098,
- "width": 22.60693596252827,
- "height": 58.77563845998762,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b33",
- "roundness": {
- "type": 2
- },
- "seed": 951248510,
- "version": 512,
- "versionNonce": 714718201,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921533353,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 22.60693596252827,
- 58.77563845998762
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "31YrT48LZ9HssKUpUQIKp",
- "focus": 0.34312299261265866,
- "gap": 12.674652099609403
- },
- "endBinding": {
- "elementId": "SAInPlPIIUsCpZmybe37z",
- "focus": -1.3155449155452992,
- "gap": 13.701058553213535
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "zdQ3h3Ds0CNMoVULQjmQ6",
- "type": "text",
- "x": 531.8579688439002,
- "y": 604.0968557504507,
- "width": 358.39971923828125,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b34",
- "roundness": null,
- "seed": 1718729506,
- "version": 406,
- "versionNonce": 637884151,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "AgRVUwHxcQ8lBlgD7BxLb",
- "type": "arrow"
- }
- ],
- "updated": 1749921718024,
- "link": null,
- "locked": false,
- "text": "kroxylicious_proxy_to_client_response_total\nkroxylicious_proxy_to_client_response_size_bytes",
- "fontSize": 16,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "kroxylicious_proxy_to_client_response_total\nkroxylicious_proxy_to_client_response_size_bytes",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "AgRVUwHxcQ8lBlgD7BxLb",
- "type": "arrow",
- "x": 647.7511418571879,
- "y": 594.5971035393595,
- "width": 41.02320966542925,
- "height": 35.976300599522006,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b35",
- "roundness": {
- "type": 2
- },
- "seed": 446576894,
- "version": 636,
- "versionNonce": 659382295,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921718024,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 41.02320966542925,
- -35.976300599522006
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "zdQ3h3Ds0CNMoVULQjmQ6",
- "focus": -0.4799115292172826,
- "gap": 9.499752211091163
- },
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "4RJBYpYMgCCAPdn4ICVRK",
- "type": "text",
- "x": 1227.973804180439,
- "y": 186.95366654029257,
- "width": 352.959716796875,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b38",
- "roundness": null,
- "seed": 636914530,
- "version": 415,
- "versionNonce": 310200377,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "SpunGs4wCrnFkk-Sb0o9v",
- "type": "arrow"
- }
- ],
- "updated": 1749921524785,
- "link": null,
- "locked": false,
- "text": "kroxylicious_proxy_to_server_request_total\nkroxylicious_proxy_to_server_request_size_bytes",
- "fontSize": 16,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "kroxylicious_proxy_to_server_request_total\nkroxylicious_proxy_to_server_request_size_bytes",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "SpunGs4wCrnFkk-Sb0o9v",
- "type": "arrow",
- "x": 1400.6972033216434,
- "y": 227.95366654029255,
- "width": 43.15981160260776,
- "height": 71.45965051982182,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b39",
- "roundness": {
- "type": 2
- },
- "seed": 1921551230,
- "version": 624,
- "versionNonce": 1341774105,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921524786,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -43.15981160260776,
- 71.45965051982182
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "4RJBYpYMgCCAPdn4ICVRK",
- "focus": -0.04734321950285547,
- "gap": 1
- },
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "hQ2cVSd1VQ_lTfj5YCEP1",
- "type": "arrow",
- "x": 1396.0801252133817,
- "y": 609.789812100082,
- "width": 48.96856576856021,
- "height": 49.94488125056807,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3B",
- "roundness": {
- "type": 2
- },
- "seed": 150217506,
- "version": 896,
- "versionNonce": 365842263,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1750068384532,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -48.96856576856021,
- -49.94488125056807
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "YvGXJnEbrx-qN5KgQVctt",
- "focus": -0.07805928795484972,
- "gap": 3.6042836875531066
- },
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "YvGXJnEbrx-qN5KgQVctt",
- "type": "text",
- "x": 1253.0195946326626,
- "y": 613.3940957876351,
- "width": 363.8717041015625,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3C",
- "roundness": null,
- "seed": 530517566,
- "version": 700,
- "versionNonce": 63122999,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "hQ2cVSd1VQ_lTfj5YCEP1",
- "type": "arrow"
- }
- ],
- "updated": 1750068384532,
- "link": null,
- "locked": false,
- "text": "kroxylicious_server_to_proxy_response_total\nkroxylicious_server_to_proxy_response_size_bytes",
- "fontSize": 16,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "kroxylicious_server_to_proxy_response_total\nkroxylicious_server_to_proxy_response_size_bytes",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "1joHi8VHLsRmRw9inw1Dv",
- "type": "rectangle",
- "x": 1513.81005859375,
- "y": 393.7366027832031,
- "width": 111.7470703125,
- "height": 80.46417236328128,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3D",
- "roundness": {
- "type": 3
- },
- "seed": 1526887714,
- "version": 429,
- "versionNonce": 1667717566,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "drQOlBjMAzQjUdkTLr9X9"
- },
- {
- "id": "heTgse6jhcXGXoaMs-Kzw",
- "type": "arrow"
- },
- {
- "id": "d4KuteymFgnAw_3DVPMbP",
- "type": "arrow"
- }
- ],
- "updated": 1749631540289,
- "link": null,
- "locked": false
- },
- {
- "id": "drQOlBjMAzQjUdkTLr9X9",
- "type": "text",
- "x": 1537.1336212158203,
- "y": 408.96868896484375,
- "width": 65.09994506835938,
- "height": 50,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3E",
- "roundness": null,
- "seed": 251363554,
- "version": 141,
- "versionNonce": 588145583,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639889912,
- "link": null,
- "locked": false,
- "text": "Kafka\nBroker",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "1joHi8VHLsRmRw9inw1Dv",
- "originalText": "Kafka Broker",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "GtdsTp3kpYBRUM9aTpRyt",
- "type": "rectangle",
- "x": 1515.4405517578125,
- "y": 494.8949890136719,
- "width": 111.7470703125,
- "height": 80.46417236328128,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3F",
- "roundness": {
- "type": 3
- },
- "seed": 593056162,
- "version": 527,
- "versionNonce": 603927407,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "j6mVIsrj3umOmqwFTkZ3W"
- }
- ],
- "updated": 1749639889640,
- "link": null,
- "locked": false
- },
- {
- "id": "j6mVIsrj3umOmqwFTkZ3W",
- "type": "text",
- "x": 1538.7641143798828,
- "y": 510.1270751953125,
- "width": 65.09994506835938,
- "height": 50,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3G",
- "roundness": null,
- "seed": 1363332450,
- "version": 319,
- "versionNonce": 89341697,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639889640,
- "link": null,
- "locked": false,
- "text": "Kafka\nBroker",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "GtdsTp3kpYBRUM9aTpRyt",
- "originalText": "Kafka Broker",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "Hhrc8s90RTDK0ggzSqVS3",
- "type": "arrow",
- "x": 550.4055786132812,
- "y": 403.13134765625,
- "width": 230.9139404296875,
- "height": 2.97314453125,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3H",
- "roundness": {
- "type": 2
- },
- "seed": 1019726946,
- "version": 82,
- "versionNonce": 1519199778,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749631439327,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 230.9139404296875,
- 2.97314453125
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "heTgse6jhcXGXoaMs-Kzw",
- "type": "arrow",
- "x": 1253.4871542331002,
- "y": 407.0094234359184,
- "width": 255.3743113765695,
- "height": 2.7329763127549995,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3J",
- "roundness": {
- "type": 2
- },
- "seed": 621302910,
- "version": 327,
- "versionNonce": 1076335489,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639587102,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 255.3743113765695,
- 2.7329763127549995
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "YYehkpK24kcUvHubWkjsE",
- "focus": -0.08142289709012389,
- "gap": 23.718996274115852
- },
- "endBinding": {
- "elementId": "1joHi8VHLsRmRw9inw1Dv",
- "focus": 0.5774028748851832,
- "gap": 5.151218060639296
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "d4KuteymFgnAw_3DVPMbP",
- "type": "arrow",
- "x": 1500.0123661996174,
- "y": 441.08918155602566,
- "width": 243.85396588411254,
- "height": 1.8775585842708438,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3K",
- "roundness": {
- "type": 2
- },
- "seed": 704968930,
- "version": 274,
- "versionNonce": 918025505,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639588718,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -243.85396588411254,
- -1.8775585842708438
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "1joHi8VHLsRmRw9inw1Dv",
- "focus": -0.18830539195807833,
- "gap": 13.797692394132582
- },
- "endBinding": {
- "elementId": "YYehkpK24kcUvHubWkjsE",
- "focus": 0.23686192962242916,
- "gap": 26.390242356520503
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "Jrz7nkKA837fykwKVwQNT",
- "type": "arrow",
- "x": 771.4397583007812,
- "y": 441.0338134765625,
- "width": 225.20562744140625,
- "height": 3.54736328125,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3L",
- "roundness": {
- "type": 2
- },
- "seed": 780056610,
- "version": 87,
- "versionNonce": 568522174,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749631489974,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -225.20562744140625,
- -3.54736328125
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "VlWVAgEMkKD78KqyIg6M0",
- "type": "text",
- "x": 571.1389770507812,
- "y": 343.682373046875,
- "width": 63.887939453125,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3M",
- "roundness": null,
- "seed": 1424808162,
- "version": 108,
- "versionNonce": 906484879,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639647352,
- "link": null,
- "locked": false,
- "text": "Produce\nRequest",
- "fontSize": 16,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "Produce\nRequest",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "wtsyzv6j_jitvoTODiiRE",
- "type": "text",
- "x": 1406.6799498337964,
- "y": 452.10096623347357,
- "width": 72.94393920898438,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3N",
- "roundness": null,
- "seed": 1220161826,
- "version": 324,
- "versionNonce": 194699905,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639950412,
- "link": null,
- "locked": false,
- "text": "Produce\nResponse",
- "fontSize": 16,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "Produce\nResponse",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "ej2TeuzJDvZ79vz0EWTrp",
- "type": "line",
- "x": 803.499286358173,
- "y": 240.25532179612378,
- "width": 1.9999483548677972,
- "height": 330.9894526554988,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3Y",
- "roundness": {
- "type": 2
- },
- "seed": 685229410,
- "version": 234,
- "versionNonce": 349956527,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639804455,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 1.9999483548677972,
- 330.9894526554988
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "SAInPlPIIUsCpZmybe37z",
- "type": "text",
- "x": 704.5740966796875,
- "y": 249.23068237304688,
- "width": 91.00791931152344,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3a",
- "roundness": null,
- "seed": 1184272162,
- "version": 169,
- "versionNonce": 1293420313,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "q2Huaio8Kx2KPfx91UdrC",
- "type": "arrow"
- }
- ],
- "updated": 1749921533352,
- "link": null,
- "locked": false,
- "text": "downstream\nmetrics",
- "fontSize": 16,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "downstream\nmetrics",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "26gt2wwZYtjwxud2sAS0D",
- "type": "line",
- "x": 1238.9365293657443,
- "y": 241.08944127336142,
- "width": 3.391315166767072,
- "height": 329.0971280611478,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3b",
- "roundness": {
- "type": 2
- },
- "seed": 576291454,
- "version": 408,
- "versionNonce": 1573265249,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639810586,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 3.391315166767072,
- 329.0971280611478
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "QyfrKr__HWhmyDvB7c84s",
- "type": "text",
- "x": 1276.0773544311523,
- "y": 245.09994506835938,
- "width": 69.58392333984375,
- "height": 40,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b3c",
- "roundness": null,
- "seed": 813057214,
- "version": 264,
- "versionNonce": 577527545,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "SpunGs4wCrnFkk-Sb0o9v",
- "type": "arrow"
- }
- ],
- "updated": 1749921690055,
- "link": null,
- "locked": false,
- "text": "upstream\nmetrics",
- "fontSize": 16,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "upstream\nmetrics",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "m403iP3j1glB8wSTbSWrk",
- "type": "rectangle",
- "x": 706.8119375171473,
- "y": 296.8037534988043,
- "width": 86.18327331542969,
- "height": 47.51734147384576,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3c8",
- "roundness": {
- "type": 3
- },
- "seed": 1551814178,
- "version": 942,
- "versionNonce": 1300294871,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "HHSSgOeNEFE95ygt5nQ5t",
- "type": "arrow"
- }
- ],
- "updated": 1749921629387,
- "link": null,
- "locked": false
- },
- {
- "id": "GmKWPcJH5CtgGDtftO5ya",
- "type": "rectangle",
- "x": 715.9057892264964,
- "y": 305.7791360905511,
- "width": 69.1299116474931,
- "height": 27.365488465729012,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3cG",
- "roundness": null,
- "seed": 1427118946,
- "version": 869,
- "versionNonce": 242553495,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "HHSSgOeNEFE95ygt5nQ5t",
- "type": "arrow"
- }
- ],
- "updated": 1749921663280,
- "link": null,
- "locked": false
- },
- {
- "id": "S-RPKzi0OwbUts3oH_wIa",
- "type": "text",
- "x": 771.8467878160855,
- "y": 300.621873571944,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3cV",
- "roundness": null,
- "seed": 832845922,
- "version": 2228,
- "versionNonce": 379600947,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "text": "2",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "2",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "8jchk8pUEJKdxnXLNgpbR",
- "type": "text",
- "x": 772.5973450810479,
- "y": 318.2338474798995,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3cd",
- "roundness": null,
- "seed": 1173205758,
- "version": 1906,
- "versionNonce": 61850067,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "text": "3",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "3",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "4BdSsQm8dXD-zZOrEA3bP",
- "type": "line",
- "x": 734.5216357120034,
- "y": 306.33150239268093,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3cl",
- "roundness": null,
- "seed": 293619198,
- "version": 846,
- "versionNonce": 1386090355,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "yZENUubagrcQChY26bnJQ",
- "type": "text",
- "x": 719.8700765760761,
- "y": 310.19033155937177,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3d",
- "roundness": null,
- "seed": 487003874,
- "version": 854,
- "versionNonce": 1974577427,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "text": "0",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "0",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "5cp9KGqhkMhYl1wH2ZYUx",
- "type": "text",
- "x": 736.5643698144979,
- "y": 309.5073811314502,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3dG",
- "roundness": null,
- "seed": 1087775266,
- "version": 916,
- "versionNonce": 1382092467,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "text": "1",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "1",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "Y08FiPpCgpEdFfLZlzKR4",
- "type": "line",
- "x": 751.4432684639567,
- "y": 305.78224523640324,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3dV",
- "roundness": null,
- "seed": 635556862,
- "version": 926,
- "versionNonce": 1532149843,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "4MKJGOCgi9oSzNpcMdtC8",
- "type": "line",
- "x": 767.0076136538216,
- "y": 305.2108701726406,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3e",
- "roundness": null,
- "seed": 1449548990,
- "version": 1002,
- "versionNonce": 1784495603,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "yi3iCDfBMxqoGq49L06Wm",
- "type": "text",
- "x": 754.5310367571121,
- "y": 310.21682249313676,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "AwwINtUjtVdXxmfmvzt9n"
- ],
- "frameId": null,
- "index": "b3f",
- "roundness": null,
- "seed": 1029226878,
- "version": 984,
- "versionNonce": 1518798739,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643284447,
- "link": null,
- "locked": false,
- "text": "7",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "7",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "E7xKrIU6f8APfWaVpI_lE",
- "type": "arrow",
- "x": 715.9171871599849,
- "y": 453.157666447095,
- "width": 0,
- "height": 45.735611234695966,
- "angle": 0,
- "strokeColor": "#e03131",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5I",
- "roundness": {
- "type": 2
- },
- "seed": 915007791,
- "version": 840,
- "versionNonce": 1076670103,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921785145,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0,
- 45.735611234695966
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "ZvEjnwzIP2pSbbpptZG1C",
- "type": "arrow",
- "x": 1339.8529265304783,
- "y": 397.188963397215,
- "width": 0.40867965719326094,
- "height": 47.382260328335576,
- "angle": 0,
- "strokeColor": "#e03131",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5K",
- "roundness": {
- "type": 2
- },
- "seed": 441815745,
- "version": 708,
- "versionNonce": 1335635225,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921788882,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -0.40867965719326094,
- -47.382260328335576
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": {
- "elementId": "JCyGHHKGu2HyY5MmL9aXt",
- "focus": -0.6930343358252623,
- "gap": 11.074075767758075
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "LGjIQBFLEiMjRB11blHG4",
- "type": "arrow",
- "x": 1339.18764984929,
- "y": 456.3145360894585,
- "width": 0,
- "height": 37.914261137039716,
- "angle": 0,
- "strokeColor": "#e03131",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5L",
- "roundness": {
- "type": 2
- },
- "seed": 226863649,
- "version": 1010,
- "versionNonce": 673154007,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921791213,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0,
- 37.914261137039716
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "7bcwJpNPt7owqySKwEaF2",
- "type": "text",
- "x": 964.7204026442308,
- "y": 248.42806302584137,
- "width": 112.07991027832031,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5M",
- "roundness": null,
- "seed": 1447433935,
- "version": 109,
- "versionNonce": 447970575,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749639931891,
- "link": null,
- "locked": false,
- "text": "Kroxylicious",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "Kroxylicious",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "HHSSgOeNEFE95ygt5nQ5t",
- "type": "arrow",
- "x": 723.2538855939182,
- "y": 395.5244363723185,
- "width": 1.3377131923639354,
- "height": 47.02507863235019,
- "angle": 0,
- "strokeColor": "#e03131",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "dotted",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5b",
- "roundness": {
- "type": 2
- },
- "seed": 869346419,
- "version": 1127,
- "versionNonce": 670743833,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921779563,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -1.3377131923639354,
- -47.02507863235019
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": {
- "elementId": "GmKWPcJH5CtgGDtftO5ya",
- "focus": 0.8405458486711315,
- "gap": 15.35473318368821
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "JCyGHHKGu2HyY5MmL9aXt",
- "type": "rectangle",
- "x": 1266.046170110288,
- "y": 291.2152858272756,
- "width": 86.18327331542969,
- "height": 47.51734147384576,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5c",
- "roundness": {
- "type": 3
- },
- "seed": 1056422899,
- "version": 995,
- "versionNonce": 3585879,
- "isDeleted": false,
- "boundElements": [
- {
- "id": "ZvEjnwzIP2pSbbpptZG1C",
- "type": "arrow"
- }
- ],
- "updated": 1749921696223,
- "link": null,
- "locked": false
- },
- {
- "id": "LDB1p8R-eNQfoNuOCq0NF",
- "type": "rectangle",
- "x": 1275.140021819637,
- "y": 300.1906684190225,
- "width": 69.1299116474931,
- "height": 27.365488465729012,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5d",
- "roundness": null,
- "seed": 1931593107,
- "version": 923,
- "versionNonce": 586015063,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false
- },
- {
- "id": "YaW1T75lbK_bxxPhrFX_H",
- "type": "text",
- "x": 1331.081020409226,
- "y": 295.03340590041523,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5e",
- "roundness": null,
- "seed": 1419352883,
- "version": 2283,
- "versionNonce": 1601543799,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "text": "2",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "2",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "GtlijYok89sJarfVCxRIk",
- "type": "text",
- "x": 1331.8315776741886,
- "y": 312.6453798083711,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5f",
- "roundness": null,
- "seed": 264617171,
- "version": 1961,
- "versionNonce": 1783150487,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "text": "3",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "3",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "9O_QXDuqyKeiWkNpb8yNm",
- "type": "line",
- "x": 1293.755868305144,
- "y": 300.7430347211524,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5g",
- "roundness": null,
- "seed": 3975795,
- "version": 901,
- "versionNonce": 429632695,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "hgecH9KuMZ25HyLmfaxz_",
- "type": "text",
- "x": 1279.1043091692165,
- "y": 304.601863887843,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5h",
- "roundness": null,
- "seed": 1254417427,
- "version": 909,
- "versionNonce": 152239575,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "text": "0",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "0",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "7plJqX1iKlwBq-Z_n7c4l",
- "type": "text",
- "x": 1295.7986024076383,
- "y": 303.9189134599218,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5i",
- "roundness": null,
- "seed": 928311731,
- "version": 971,
- "versionNonce": 1807952631,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "text": "1",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "1",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "trcIW0quW7v2gxM0I27Ft",
- "type": "line",
- "x": 1310.6775010570966,
- "y": 300.1937775648747,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5j",
- "roundness": null,
- "seed": 1259551571,
- "version": 981,
- "versionNonce": 506508311,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "tapO-cbwLYJC42200-gTR",
- "type": "line",
- "x": 1326.2418462469616,
- "y": 299.6224025011119,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5k",
- "roundness": null,
- "seed": 576084211,
- "version": 1057,
- "versionNonce": 2018515255,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "1g53KbZltmbdpqvopiHsk",
- "type": "text",
- "x": 1313.7652693502525,
- "y": 304.62835482160824,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "c9QObcSmi-lzRVzIJEGB_"
- ],
- "frameId": null,
- "index": "b5l",
- "roundness": null,
- "seed": 178569875,
- "version": 1039,
- "versionNonce": 1602607703,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921692806,
- "link": null,
- "locked": false,
- "text": "7",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "7",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "aXBN1Tfvkzpo2X1nkIDh6",
- "type": "rectangle",
- "x": 1268.5227909917419,
- "y": 505.45601909833516,
- "width": 86.18327331542969,
- "height": 47.51734147384576,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5m",
- "roundness": {
- "type": 3
- },
- "seed": 534057021,
- "version": 919,
- "versionNonce": 249664339,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false
- },
- {
- "id": "oROL5txpxB2Ir5Flf-LYp",
- "type": "rectangle",
- "x": 1277.616642701091,
- "y": 514.4314016900821,
- "width": 69.1299116474931,
- "height": 27.365488465729012,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5n",
- "roundness": null,
- "seed": 446824605,
- "version": 848,
- "versionNonce": 177844467,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false
- },
- {
- "id": "q98SL5Pc0DAwsjURpMQIu",
- "type": "text",
- "x": 1333.55764129068,
- "y": 509.2741391714748,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5o",
- "roundness": null,
- "seed": 590472445,
- "version": 2208,
- "versionNonce": 1086134931,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "text": "2",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "2",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "zqoRhglGV2YXFri7YK33m",
- "type": "text",
- "x": 1334.3081985556425,
- "y": 526.8861130794307,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5p",
- "roundness": null,
- "seed": 1829125469,
- "version": 1886,
- "versionNonce": 1577209907,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "text": "3",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "3",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "vUISMRIGiuuEJfD8XcrTU",
- "type": "line",
- "x": 1296.232489186598,
- "y": 514.983767992212,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5q",
- "roundness": null,
- "seed": 1064339901,
- "version": 826,
- "versionNonce": 877646291,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "C2COpF6Bqr4mT8oJXenNv",
- "type": "text",
- "x": 1281.5809300506705,
- "y": 518.8425971589027,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5r",
- "roundness": null,
- "seed": 2073184797,
- "version": 834,
- "versionNonce": 347873139,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "text": "0",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "0",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "QFrYGijlwh2qoJHPwbsCe",
- "type": "text",
- "x": 1298.2752232890923,
- "y": 518.1596467309814,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5s",
- "roundness": null,
- "seed": 1650261629,
- "version": 896,
- "versionNonce": 1770895635,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "text": "1",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "1",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "JaYn4_u_Qlj6OftqG_07c",
- "type": "line",
- "x": 1313.1541219385506,
- "y": 514.4345108359344,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5t",
- "roundness": null,
- "seed": 445785821,
- "version": 906,
- "versionNonce": 272309939,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "RudsI3WzU8dMI8K8cHTq-",
- "type": "line",
- "x": 1328.7184671284156,
- "y": 513.8631357721715,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5u",
- "roundness": null,
- "seed": 1992508221,
- "version": 982,
- "versionNonce": 1936379987,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "_FNkJ10VHj1q4iuxoemIm",
- "type": "text",
- "x": 1316.2418902317065,
- "y": 518.8690880926679,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "RdrSTI_0-e3FQkxosSbLU"
- ],
- "frameId": null,
- "index": "b5v",
- "roundness": null,
- "seed": 2068960157,
- "version": 964,
- "versionNonce": 1693666803,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643315788,
- "link": null,
- "locked": false,
- "text": "7",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "7",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "2bDoXwWzDMEHuJD0828VD",
- "type": "rectangle",
- "x": 693.9214832471762,
- "y": 507.3863753313517,
- "width": 86.18327331542969,
- "height": 47.51734147384576,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b5w",
- "roundness": {
- "type": 3
- },
- "seed": 1505483837,
- "version": 952,
- "versionNonce": 1444717107,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false
- },
- {
- "id": "ku3wPSRvuGE32n0M0oeZg",
- "type": "rectangle",
- "x": 703.0153349565253,
- "y": 516.3617579230986,
- "width": 69.1299116474931,
- "height": 27.365488465729012,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b5x",
- "roundness": null,
- "seed": 97471645,
- "version": 881,
- "versionNonce": 424666067,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false
- },
- {
- "id": "dTKNjtFLdYGlfEopKTK0c",
- "type": "text",
- "x": 758.9563335461144,
- "y": 511.20449540449135,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b5y",
- "roundness": null,
- "seed": 1389736189,
- "version": 2241,
- "versionNonce": 1139405171,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "text": "2",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "2",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "mR4QOpCxDuJtpZgzjd-VK",
- "type": "text",
- "x": 759.7068908110768,
- "y": 528.8164693124472,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b5z",
- "roundness": null,
- "seed": 240159069,
- "version": 1919,
- "versionNonce": 1462848275,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "text": "3",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "3",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "HPteCSVoilkxUBFXyVuiW",
- "type": "line",
- "x": 721.6311814420324,
- "y": 516.9141242252285,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b60",
- "roundness": null,
- "seed": 1502696893,
- "version": 859,
- "versionNonce": 1738305715,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "Cj_SY32y1lXaPNHJIEMIF",
- "type": "text",
- "x": 706.9796223061048,
- "y": 520.7729533919191,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b61",
- "roundness": null,
- "seed": 800691741,
- "version": 867,
- "versionNonce": 919724627,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "text": "0",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "0",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "HM5rXoV8CWOObU7-2u7Ay",
- "type": "text",
- "x": 723.6739155445266,
- "y": 520.0900029639979,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b62",
- "roundness": null,
- "seed": 733661821,
- "version": 929,
- "versionNonce": 229122035,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "text": "1",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "1",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "_u4HcF0vXC9QRsq_6eYpf",
- "type": "line",
- "x": 738.5528141939849,
- "y": 516.3648670689508,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b63",
- "roundness": null,
- "seed": 240546525,
- "version": 939,
- "versionNonce": 1445308819,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "-AqjfwMUJoUVgymS1NpUk",
- "type": "line",
- "x": 754.1171593838499,
- "y": 515.793492005188,
- "width": 0.4588897056957841,
- "height": 27.254974761129365,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b64",
- "roundness": null,
- "seed": 69078845,
- "version": 1015,
- "versionNonce": 1971388211,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0.4588897056957841,
- 27.254974761129365
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": null,
- "endBinding": null,
- "startArrowhead": null,
- "endArrowhead": null,
- "polygon": false
- },
- {
- "id": "ccZKQtPCEsiiTrRUMiaeg",
- "type": "text",
- "x": 741.6405824871408,
- "y": 520.7994443256844,
- "width": 9.939560125309763,
- "height": 20.707416927728673,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [
- "R-lFyda0zNhx8NQ9CQT_v"
- ],
- "frameId": null,
- "index": "b65",
- "roundness": null,
- "seed": 728965021,
- "version": 997,
- "versionNonce": 1713414355,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749643309770,
- "link": null,
- "locked": false,
- "text": "7",
- "fontSize": 16.56593354218294,
- "fontFamily": 6,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "7",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "sBj7DTJR46pgTEXyvP53W",
- "type": "text",
- "x": 734.7414093017578,
- "y": 352.0391808534279,
- "width": 63.23193359375,
- "height": 40,
- "angle": 0,
- "strokeColor": "#e03131",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 4,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b67",
- "roundness": null,
- "seed": 1610659799,
- "version": 131,
- "versionNonce": 447932055,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1749921781928,
- "link": null,
- "locked": false,
- "text": "+1\n+size(m)",
- "fontSize": 16,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "+1\n+size(m)",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "l3Z_sRlBiTbdnHQVasLue",
- "type": "text",
- "x": 1266.2545928955078,
- "y": 459.2332116151467,
- "width": 63.23193359375,
- "height": 40,
- "angle": 0,
- "strokeColor": "#e03131",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 4,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b69",
- "roundness": null,
- "seed": 1210212151,
- "version": 244,
- "versionNonce": 149723353,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1749921796796,
- "link": null,
- "locked": false,
- "text": "+1\n+size(m)",
- "fontSize": 16,
- "fontFamily": 5,
- "textAlign": "left",
- "verticalAlign": "top",
- "containerId": null,
- "originalText": "+1\n+size(m)",
- "autoResize": true,
- "lineHeight": 1.25
- }
- ],
- "appState": {
- "gridSize": 20,
- "gridStep": 5,
- "gridModeEnabled": false,
- "viewBackgroundColor": "#ffffff",
- "lockedMultiSelections": {}
- },
- "files": {}
-}
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/_assets/monitoring-message-counters.svg b/docs/v0.13.0/_files/_assets/monitoring-message-counters.svg
deleted file mode 100644
index e84f4451..00000000
--- a/docs/v0.13.0/_files/_assets/monitoring-message-counters.svg
+++ /dev/null
@@ -1,5 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/_assets/operator-diagrams.excalidraw b/docs/v0.13.0/_files/_assets/operator-diagrams.excalidraw
deleted file mode 100644
index ca77c3ee..00000000
--- a/docs/v0.13.0/_files/_assets/operator-diagrams.excalidraw
+++ /dev/null
@@ -1,1488 +0,0 @@
-{
- "type": "excalidraw",
- "version": 2,
- "source": "https://excalidraw.com",
- "elements": [
- {
- "id": "Pg258tRIJ3LJ2y7p0CnXC",
- "type": "rectangle",
- "x": 916.6666666666666,
- "y": 4440.11110941569,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b59",
- "roundness": {
- "type": 3
- },
- "seed": 1482719467,
- "version": 39,
- "versionNonce": 284863659,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "DbzGHPWQqLrinEXCVCNxT"
- },
- {
- "id": "BuI552-7b0_tvzweQnPi8",
- "type": "arrow"
- },
- {
- "id": "xtaFqPeF8Uw_O5rT7iDxT",
- "type": "arrow"
- },
- {
- "id": "tQSvi8UOgewUrF-bAIlRG",
- "type": "arrow"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "DbzGHPWQqLrinEXCVCNxT",
- "type": "text",
- "x": 969.755522410075,
- "y": 4482.055549621582,
- "width": 111.5999984741211,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5A",
- "roundness": null,
- "seed": 1731961541,
- "version": 24,
- "versionNonce": 315885445,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "KafkaProxy",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "Pg258tRIJ3LJ2y7p0CnXC",
- "originalText": "KafkaProxy",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "rIjpmG2dmZX1PgU-Wq5E_",
- "type": "rectangle",
- "x": 1085.5555216471353,
- "y": 4619.000027974447,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5B",
- "roundness": {
- "type": 3
- },
- "seed": 186107755,
- "version": 119,
- "versionNonce": 972414795,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "FWxQkcgT7C5N_cv1C1lC5"
- },
- {
- "id": "BuI552-7b0_tvzweQnPi8",
- "type": "arrow"
- },
- {
- "id": "cTdAFKnrLHAZy103agKF-",
- "type": "arrow"
- },
- {
- "id": "CSWPTl69pYH1XRNwWJWwD",
- "type": "arrow"
- },
- {
- "id": "OJxuc78nP4jDyk9npcpUW",
- "type": "arrow"
- },
- {
- "id": "WuMgNwNqqJ8HwKBQNJswd",
- "type": "arrow"
- },
- {
- "id": "1hYu6WM-w63jAlpO5ZwZS",
- "type": "arrow"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "FWxQkcgT7C5N_cv1C1lC5",
- "type": "text",
- "x": 1100.356875101725,
- "y": 4660.944468180339,
- "width": 188.1750030517578,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5C",
- "roundness": null,
- "seed": 253862411,
- "version": 123,
- "versionNonce": 1884475109,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "VirtualKafkaCluster",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "rIjpmG2dmZX1PgU-Wq5E_",
- "originalText": "VirtualKafkaCluster",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "XxrEN1my564DCRVc6J0Nq",
- "type": "rectangle",
- "x": 745.5555216471349,
- "y": 4619.444404602051,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5D",
- "roundness": {
- "type": 3
- },
- "seed": 1937526661,
- "version": 380,
- "versionNonce": 238140907,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "X2aXy7n00ZRF3KgqNL6xv"
- },
- {
- "id": "xtaFqPeF8Uw_O5rT7iDxT",
- "type": "arrow"
- },
- {
- "id": "cTdAFKnrLHAZy103agKF-",
- "type": "arrow"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "X2aXy7n00ZRF3KgqNL6xv",
- "type": "text",
- "x": 762.0943781534827,
- "y": 4661.388844807942,
- "width": 184.6999969482422,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5E",
- "roundness": null,
- "seed": 615651045,
- "version": 400,
- "versionNonce": 1967237701,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "KafkaProxyIngress",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "XxrEN1my564DCRVc6J0Nq",
- "originalText": "KafkaProxyIngress",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "feZCdlb2VRdqnBsevHq2f",
- "type": "rectangle",
- "x": 1443.3333841959638,
- "y": 4620.111122131348,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5F",
- "roundness": {
- "type": 3
- },
- "seed": 115767563,
- "version": 129,
- "versionNonce": 951634059,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "5a-758P4NAhe1vpT6Ue3W"
- },
- {
- "id": "CSWPTl69pYH1XRNwWJWwD",
- "type": "arrow"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "5a-758P4NAhe1vpT6Ue3W",
- "type": "text",
- "x": 1490.7097384134931,
- "y": 4662.055562337239,
- "width": 123.0250015258789,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5G",
- "roundness": null,
- "seed": 761864107,
- "version": 133,
- "versionNonce": 1652431269,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "KafkaService",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "feZCdlb2VRdqnBsevHq2f",
- "originalText": "KafkaService",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "o9O-r3tFxSMYUh6sUgxHW",
- "type": "rectangle",
- "x": 1096.7778116861978,
- "y": 4801.222216288249,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5H",
- "roundness": {
- "type": 3
- },
- "seed": 1819598853,
- "version": 173,
- "versionNonce": 524648235,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "VOnE_Hw4cEI_ZJYZ1r1yN"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "VOnE_Hw4cEI_ZJYZ1r1yN",
- "type": "text",
- "x": 1109.5791651407876,
- "y": 4843.166656494141,
- "width": 192.1750030517578,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5I",
- "roundness": null,
- "seed": 21272421,
- "version": 198,
- "versionNonce": 20290821,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "KafkaProtocolFilter",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "o9O-r3tFxSMYUh6sUgxHW",
- "originalText": "KafkaProtocolFilter",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "BuI552-7b0_tvzweQnPi8",
- "type": "arrow",
- "x": 1122.44332653981,
- "y": 4620.28411178941,
- "width": 35.25050805529918,
- "height": 69.23487847386514,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5J",
- "roundness": {
- "type": 2
- },
- "seed": 1779646629,
- "version": 110,
- "versionNonce": 205677003,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -35.25050805529918,
- -69.23487847386514
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "rIjpmG2dmZX1PgU-Wq5E_",
- "focus": -0.32893013522688047,
- "gap": 1.2840838149631963
- },
- "endBinding": {
- "elementId": "Pg258tRIJ3LJ2y7p0CnXC",
- "focus": -0.24064236015616552,
- "gap": 2.0492434880716246
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "xtaFqPeF8Uw_O5rT7iDxT",
- "type": "arrow",
- "x": 927.8132106243377,
- "y": 4618.641963856848,
- "width": 42.83051783154099,
- "height": 69.19151348757896,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5K",
- "roundness": {
- "type": 2
- },
- "seed": 2065572261,
- "version": 313,
- "versionNonce": 417707109,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 42.83051783154099,
- -69.19151348757896
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "XxrEN1my564DCRVc6J0Nq",
- "focus": 0.26356685160400894,
- "gap": 1.77172777200758
- },
- "endBinding": {
- "elementId": "Pg258tRIJ3LJ2y7p0CnXC",
- "focus": 0.16811276167481815,
- "gap": 1
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "cTdAFKnrLHAZy103agKF-",
- "type": "arrow",
- "x": 1084.3693525271167,
- "y": 4665.571139546195,
- "width": 117.1544300954098,
- "height": 0.3657568025364526,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5L",
- "roundness": {
- "type": 2
- },
- "seed": 1542672517,
- "version": 329,
- "versionNonce": 415887467,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -117.1544300954098,
- 0.3657568025364526
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "rIjpmG2dmZX1PgU-Wq5E_",
- "focus": 0.14998767377465488,
- "gap": 1.186169120018576
- },
- "endBinding": {
- "elementId": "XxrEN1my564DCRVc6J0Nq",
- "focus": -0.13872341946199118,
- "gap": 3.881690823634358
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "CSWPTl69pYH1XRNwWJWwD",
- "type": "arrow",
- "x": 1304.444478352865,
- "y": 4671.222279866537,
- "width": 136.66666666666652,
- "height": 2.22218831380178,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5Q",
- "roundness": {
- "type": 2
- },
- "seed": 1064189765,
- "version": 32,
- "versionNonce": 626778053,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 136.66666666666652,
- 2.22218831380178
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "rIjpmG2dmZX1PgU-Wq5E_",
- "focus": -0.0713472054332695,
- "gap": 1.1112467447921972
- },
- "endBinding": {
- "elementId": "feZCdlb2VRdqnBsevHq2f",
- "focus": -0.012373266611279661,
- "gap": 2.2222391764323675
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "mNbITRWs-W0lS2byRmWOa",
- "type": "rectangle",
- "x": 1086.777811686198,
- "y": 4816.7778396606445,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5R",
- "roundness": {
- "type": 3
- },
- "seed": 385693355,
- "version": 201,
- "versionNonce": 1453763339,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "EEK9CisK5jvpU858bzl3O"
- },
- {
- "id": "OJxuc78nP4jDyk9npcpUW",
- "type": "arrow"
- },
- {
- "id": "WuMgNwNqqJ8HwKBQNJswd",
- "type": "arrow"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "EEK9CisK5jvpU858bzl3O",
- "type": "text",
- "x": 1099.5791651407878,
- "y": 4858.722279866536,
- "width": 192.1750030517578,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5S",
- "roundness": null,
- "seed": 857155915,
- "version": 224,
- "versionNonce": 1286971173,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "KafkaProtocolFilter",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "mNbITRWs-W0lS2byRmWOa",
- "originalText": "KafkaProtocolFilter",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "OJxuc78nP4jDyk9npcpUW",
- "type": "arrow",
- "x": 1235.7197886819915,
- "y": 4730.4685123612435,
- "width": 6.733548942860807,
- "height": 59.794132047241874,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5T",
- "roundness": {
- "type": 2
- },
- "seed": 1679701253,
- "version": 99,
- "versionNonce": 978522539,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 6.733548942860807,
- 59.794132047241874
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "rIjpmG2dmZX1PgU-Wq5E_",
- "focus": -0.3030239951146618,
- "gap": 2.579603975013015
- },
- "endBinding": {
- "elementId": "mNbITRWs-W0lS2byRmWOa",
- "focus": 0.48603487818228525,
- "gap": 26.515195252159174
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "WuMgNwNqqJ8HwKBQNJswd",
- "type": "arrow",
- "x": 1178.5649214041473,
- "y": 4728.898512312885,
- "width": 8.280896828718596,
- "height": 87.4288668059653,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5U",
- "roundness": {
- "type": 2
- },
- "seed": 380289963,
- "version": 70,
- "versionNonce": 358642309,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -8.280896828718596,
- 87.4288668059653
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "rIjpmG2dmZX1PgU-Wq5E_",
- "focus": 0.08859212323079159,
- "gap": 2.222201029459029
- },
- "endBinding": {
- "elementId": "mNbITRWs-W0lS2byRmWOa",
- "focus": -0.26719361792643076,
- "gap": 1
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "15_6c51SAvyzG3tVVyKdV",
- "type": "rectangle",
- "x": 732.2221883138022,
- "y": 4634.555600484213,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5V",
- "roundness": {
- "type": 3
- },
- "seed": 619683915,
- "version": 431,
- "versionNonce": 1157211211,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "XJV1ywBSIB8nbRNI-DwjH"
- },
- {
- "id": "1hYu6WM-w63jAlpO5ZwZS",
- "type": "arrow"
- },
- {
- "id": "tQSvi8UOgewUrF-bAIlRG",
- "type": "arrow"
- }
- ],
- "updated": 1745362294624,
- "link": null,
- "locked": false
- },
- {
- "id": "XJV1ywBSIB8nbRNI-DwjH",
- "type": "text",
- "x": 748.76104482015,
- "y": 4676.5000406901045,
- "width": 184.6999969482422,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5W",
- "roundness": null,
- "seed": 1447780075,
- "version": 449,
- "versionNonce": 1545198053,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "text": "KafkaProxyIngress",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "15_6c51SAvyzG3tVVyKdV",
- "originalText": "KafkaProxyIngress",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "1hYu6WM-w63jAlpO5ZwZS",
- "type": "arrow",
- "x": 1084.4444783528647,
- "y": 4699.0000406901045,
- "width": 135.55557250976562,
- "height": 1.1110941569013448,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5X",
- "roundness": {
- "type": 2
- },
- "seed": 1211900389,
- "version": 39,
- "versionNonce": 1853154027,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- -135.55557250976562,
- 1.1110941569013448
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "rIjpmG2dmZX1PgU-Wq5E_",
- "focus": -0.4455240896553285,
- "gap": 1.1110432942705302
- },
- "endBinding": {
- "elementId": "15_6c51SAvyzG3tVVyKdV",
- "focus": 0.21675397576676844,
- "gap": 1.1109924316407387
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "tQSvi8UOgewUrF-bAIlRG",
- "type": "arrow",
- "x": 865.5555725097657,
- "y": 4634.55561319987,
- "width": 64.44442749023438,
- "height": 91.11111958821584,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5Y",
- "roundness": {
- "type": 2
- },
- "seed": 1616313221,
- "version": 38,
- "versionNonce": 166679877,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362294624,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 64.44442749023438,
- -91.11111958821584
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "15_6c51SAvyzG3tVVyKdV",
- "focus": -0.09542123582067086,
- "gap": 1
- },
- "endBinding": {
- "elementId": "Pg258tRIJ3LJ2y7p0CnXC",
- "focus": 0.4136787162645928,
- "gap": 2.815734333086908
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "tIRExJKHrZiZMs90Sn44P",
- "type": "rectangle",
- "x": 1019.9998982747397,
- "y": 5036.555575052897,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5Z",
- "roundness": {
- "type": 3
- },
- "seed": 1227007403,
- "version": 349,
- "versionNonce": 570417285,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "DVqjb_iF4B8zabfOQ8Mh2"
- },
- {
- "id": "LejYsXJ06UkyuOI0z2_MF",
- "type": "arrow"
- }
- ],
- "updated": 1745362569473,
- "link": null,
- "locked": false
- },
- {
- "id": "DVqjb_iF4B8zabfOQ8Mh2",
- "type": "text",
- "x": 1073.813752492269,
- "y": 5078.500015258789,
- "width": 110.1500015258789,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5a",
- "roundness": null,
- "seed": 2092349515,
- "version": 344,
- "versionNonce": 390036843,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362564152,
- "link": null,
- "locked": false,
- "text": "Deployment",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "tIRExJKHrZiZMs90Sn44P",
- "originalText": "Deployment",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "Mrp2zx_7sac33qNe6rYj0",
- "type": "rectangle",
- "x": 1018.8889567057295,
- "y": 5203.444404602052,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5b",
- "roundness": {
- "type": 3
- },
- "seed": 497074373,
- "version": 298,
- "versionNonce": 1275806533,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "Vg5XpJoIe9Q8JytXYRoWm"
- },
- {
- "id": "qeEjFzu3CV0pj-imWcBjS",
- "type": "arrow"
- },
- {
- "id": "DtvsjrnRzZ-bJn7vUwAIL",
- "type": "arrow"
- },
- {
- "id": "LejYsXJ06UkyuOI0z2_MF",
- "type": "arrow"
- }
- ],
- "updated": 1745362569473,
- "link": null,
- "locked": false
- },
- {
- "id": "Vg5XpJoIe9Q8JytXYRoWm",
- "type": "text",
- "x": 1108.9778124491377,
- "y": 5245.388844807943,
- "width": 37.599998474121094,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5c",
- "roundness": null,
- "seed": 196501541,
- "version": 285,
- "versionNonce": 1879920203,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362508212,
- "link": null,
- "locked": false,
- "text": "Pod",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "Mrp2zx_7sac33qNe6rYj0",
- "originalText": "Pod",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "ZSYXuc-RzvQLR3cE0AWZu",
- "type": "rectangle",
- "x": 1338.3333333333337,
- "y": 5204.555651346844,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5d",
- "roundness": {
- "type": 3
- },
- "seed": 88519627,
- "version": 329,
- "versionNonce": 568475717,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "5hQH13sFbEk24LAHH1ohV"
- },
- {
- "id": "DtvsjrnRzZ-bJn7vUwAIL",
- "type": "arrow"
- }
- ],
- "updated": 1745362539732,
- "link": null,
- "locked": false
- },
- {
- "id": "5hQH13sFbEk24LAHH1ohV",
- "type": "text",
- "x": 1397.734689076742,
- "y": 5246.500091552735,
- "width": 98.9749984741211,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5e",
- "roundness": null,
- "seed": 1366557291,
- "version": 325,
- "versionNonce": 1628965163,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362539732,
- "link": null,
- "locked": false,
- "text": "ConfigMap",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "ZSYXuc-RzvQLR3cE0AWZu",
- "originalText": "ConfigMap",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "Y95V1-RZFNN96O-4-CXHK",
- "type": "rectangle",
- "x": 682.2222900390626,
- "y": 5206.777788798014,
- "width": 217.7777099609376,
- "height": 108.88888041178323,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5f",
- "roundness": {
- "type": 3
- },
- "seed": 966589099,
- "version": 357,
- "versionNonce": 1858438091,
- "isDeleted": false,
- "boundElements": [
- {
- "type": "text",
- "id": "1fwiyiDckiFhBRMqsPert"
- },
- {
- "id": "qeEjFzu3CV0pj-imWcBjS",
- "type": "arrow"
- }
- ],
- "updated": 1745362523883,
- "link": null,
- "locked": false
- },
- {
- "id": "1fwiyiDckiFhBRMqsPert",
- "type": "text",
- "x": 757.161144256592,
- "y": 5248.722229003905,
- "width": 67.9000015258789,
- "height": 25,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "transparent",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5g",
- "roundness": null,
- "seed": 1964928331,
- "version": 362,
- "versionNonce": 1679364453,
- "isDeleted": false,
- "boundElements": [],
- "updated": 1745362517183,
- "link": null,
- "locked": false,
- "text": "Service",
- "fontSize": 20,
- "fontFamily": 5,
- "textAlign": "center",
- "verticalAlign": "middle",
- "containerId": "Y95V1-RZFNN96O-4-CXHK",
- "originalText": "Service",
- "autoResize": true,
- "lineHeight": 1.25
- },
- {
- "id": "qeEjFzu3CV0pj-imWcBjS",
- "type": "arrow",
- "x": 898.8889058430991,
- "y": 5260.111134847006,
- "width": 116.6666158040365,
- "height": 1.1110941569013448,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5h",
- "roundness": {
- "type": 2
- },
- "seed": 1250770443,
- "version": 47,
- "versionNonce": 1746360235,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362674573,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 116.6666158040365,
- -1.1110941569013448
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "Y95V1-RZFNN96O-4-CXHK",
- "focus": -0.001525816092728325,
- "gap": 1.1110941569011175
- },
- "endBinding": {
- "elementId": "Mrp2zx_7sac33qNe6rYj0",
- "focus": -0.0007647240847281679,
- "gap": 3.3334350585938637
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "DtvsjrnRzZ-bJn7vUwAIL",
- "type": "arrow",
- "x": 1237.5594630041858,
- "y": 5263.44395814927,
- "width": 98.7942661626023,
- "height": 0.002866898660613515,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5i",
- "roundness": {
- "type": 2
- },
- "seed": 728838277,
- "version": 55,
- "versionNonce": 1080010987,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362674573,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 98.7942661626023,
- -0.002866898660613515
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "Mrp2zx_7sac33qNe6rYj0",
- "focus": 0.10208529076887765,
- "gap": 1
- },
- "endBinding": {
- "elementId": "ZSYXuc-RzvQLR3cE0AWZu",
- "focus": -0.08150556528808393,
- "gap": 1.9796041665456414
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- },
- {
- "id": "LejYsXJ06UkyuOI0z2_MF",
- "type": "arrow",
- "x": 1126.666666666667,
- "y": 5151.222279866537,
- "width": 0,
- "height": 50,
- "angle": 0,
- "strokeColor": "#1e1e1e",
- "backgroundColor": "#ffffff",
- "fillStyle": "solid",
- "strokeWidth": 2,
- "strokeStyle": "solid",
- "roughness": 1,
- "opacity": 100,
- "groupIds": [],
- "frameId": null,
- "index": "b5j",
- "roundness": {
- "type": 2
- },
- "seed": 1759680523,
- "version": 22,
- "versionNonce": 154446379,
- "isDeleted": false,
- "boundElements": null,
- "updated": 1745362674573,
- "link": null,
- "locked": false,
- "points": [
- [
- 0,
- 0
- ],
- [
- 0,
- 50
- ]
- ],
- "lastCommittedPoint": null,
- "startBinding": {
- "elementId": "tIRExJKHrZiZMs90Sn44P",
- "focus": 0.02040692400466519,
- "gap": 5.777824401856378
- },
- "endBinding": {
- "elementId": "Mrp2zx_7sac33qNe6rYj0",
- "focus": -0.01020439621419884,
- "gap": 2.222124735514626
- },
- "startArrowhead": null,
- "endArrowhead": "arrow",
- "elbowed": false
- }
- ],
- "appState": {
- "gridSize": 20,
- "gridStep": 5,
- "gridModeEnabled": false,
- "viewBackgroundColor": "#ffffff"
- },
- "files": {}
-}
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/_assets/operator-input-resource-topology.svg b/docs/v0.13.0/_files/_assets/operator-input-resource-topology.svg
deleted file mode 100644
index 6865d8d4..00000000
--- a/docs/v0.13.0/_files/_assets/operator-input-resource-topology.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/_assets/operator-output-resource-topology.svg b/docs/v0.13.0/_files/_assets/operator-output-resource-topology.svg
deleted file mode 100644
index 9e1d2b10..00000000
--- a/docs/v0.13.0/_files/_assets/operator-output-resource-topology.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/_assets/trademarks.adoc b/docs/v0.13.0/_files/_assets/trademarks.adoc
deleted file mode 100644
index f7c2982c..00000000
--- a/docs/v0.13.0/_files/_assets/trademarks.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-= Trademark notice
-
-* Apache Kafka is a registered trademark of The Apache Software Foundation.
-* Kubernetes is a registered trademark of The Linux Foundation.
-* Prometheus is a registered trademark of The Linux Foundation.
-* Strimzi is a trademark of The Linux Foundation.
-* Hashicorp Vault is a registered trademark of HashiCorp, Inc.
-* AWS Key Management Service is a trademark of Amazon.com, Inc. or its affiliates.
-ifdef::include-fortanix-dsm-kms[]
-* Fortanix and Data Security Manager are trademarks of Fortanix, Inc.
-endif::[]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-aws-kms.adoc b/docs/v0.13.0/_files/assemblies/assembly-aws-kms.adoc
deleted file mode 100644
index 19180bd1..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-aws-kms.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// file included in the following:
-//
-// assembly-record-encryption-filter.adoc
-
-[id='assembly-aws-kms-{context}']
-= Preparing AWS KMS
-
-[role="_abstract"]
-To prepare {aws}/kms/latest/developerguide/overview.html[AWS Key Management Service] for use with the Record Encryption filter, use the following setup:
-
-* Establish an AWS KMS aliasing convention for keys
-* Create AWS KMS keys
-
-You'll need a privileged AWS user that is capable of creating users and policies to perform the set-up.
-
-include::../modules/record-encryption/aws-kms/con-aws-kms-setup.adoc[leveloffset=+1]
-include::../modules/record-encryption/aws-kms/con-aws-kms-key-creation.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-built-in-filters.adoc b/docs/v0.13.0/_files/assemblies/assembly-built-in-filters.adoc
deleted file mode 100644
index d3f8e891..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-built-in-filters.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-proxy/index.adoc
-
-[id='assembly-built-in-filters-{context}']
-= Built-in filters
-
-[role="_abstract"]
-Kroxylicious comes with a suite of built-in filters designed to enhance the functionality and security of your Kafka clusters.
-
-== Record Encryption filter
-
-The Kroxylicious Record Encryption filter enables encryption-at-rest for Apache Kafka clusters.
-For information on using the filter, see the {RecordEncryptionGuide}.
-
-include::assembly-multi-tenancy-filter.adoc[leveloffset=+1]
-include::assembly-record-validation-filter.adoc[leveloffset=+1]
-include::../modules/oauthbearer/con-oauthbearer.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-configuring-proxy.adoc b/docs/v0.13.0/_files/assemblies/assembly-configuring-proxy.adoc
deleted file mode 100644
index b7df6fd6..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-configuring-proxy.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-[id='assembly-configuring-proxy-{context}']
-= Configuring proxies
-
-[role="_abstract"]
-Fine-tune your deployment by configuring proxies to include additional features according to your specific requirements.
-
-include::../modules/configuring/con-configuration-outline.adoc[leveloffset=+1]
-include::../modules/configuring/con-configuring-filters.adoc[leveloffset=+1]
-include::../modules/configuring/con-configuring-virtual-clusters.adoc[leveloffset=+1]
-include::../modules/configuring/con-configuring-vc-gateways.adoc[leveloffset=+1]
-include::../modules/configuring/con-configuring-vc-client-tls.adoc[leveloffset=+1]
-include::../modules/configuring/con-configuring-vc-target-tls.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-configuring-vc-other-settings.adoc[leveloffset=+1]
-include::../modules/configuring/con-configuring-toplevel-other-settings.adoc[leveloffset=+1]
-
-include::../modules/configuring/ref-configuring-proxy-example.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-configuring-record-encryption-filter.adoc b/docs/v0.13.0/_files/assemblies/assembly-configuring-record-encryption-filter.adoc
deleted file mode 100644
index e96d004f..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-configuring-record-encryption-filter.adoc
+++ /dev/null
@@ -1,57 +0,0 @@
-// file included in the following:
-//
-// record-encryption-guide/index.adoc
-
-[id='proc-configuring-record-encryption-filter-{context}']
-= Configuring the Record Encryption filter
-
-[role="_abstract"]
-This section describes at a high level how to configure the Record Encryption filter using a previously prepared KMS.
-Subsections provide in-depth details.
-
-.Prerequisites
-
-* An instance of Kroxylicious. +
-For information on deploying Kroxylicious, see the {ProxyGuide} or {OperatorGuide}.
-* A KMS has been prepared for use by the filter, with KEKs to encrypt records set up for topics.
-
-.Procedure
-
-. Configure the plugin for your supported KMS, as required.
-+
-* <>
-* <>
-ifdef::include-fortanix-dsm-kms[]
-* <>
-endif::[]
-
-. Create a filter configuration that references the configured KMS plugins.
-+
-See <>
-
-. Apply the filter configuration:
-
-ifdef::include-platform-bare-metal[]
-* In a standalone proxy deployment. See <>
-endif::[]
-ifdef::include-platform-kubernetes[]
-* In a Kubernetes deployment using a `KafkaProcotolFilter` resource. See <>
-endif::[]
-
-include::../modules/record-encryption/hashicorp-vault/con-vault-plugin-configuration.adoc[leveloffset=+1]
-
-include::../modules/record-encryption/aws-kms/con-aws-kms-plugin-configuration.adoc[leveloffset=+1]
-
-ifdef::include-fortanix-dsm-kms[]
-include::../modules/record-encryption/fortanix-dsm/con-fortanix-dsm-plugin-configuration.adoc[leveloffset=+1]
-endif::[]
-
-include::../modules/record-encryption/con-record-encryption-filter-config.adoc[leveloffset=+1]
-
-ifdef::include-platform-bare-metal[]
-include::../modules/record-encryption/con-example-proxy-config.adoc[leveloffset=+1]
-endif::[]
-
-ifdef::include-platform-kubernetes[]
-include::../modules/record-encryption/con-example-kafkaprotocolfilter-resource.adoc[leveloffset=+1]
-endif::[]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-fortanix-dsm.adoc b/docs/v0.13.0/_files/assemblies/assembly-fortanix-dsm.adoc
deleted file mode 100644
index b7a0cbfa..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-fortanix-dsm.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-// file included in the following:
-//
-// assembly-record-encryption-filter.adoc
-
-[id='assembly-fortanix-dsm-{context}']
-= Preparing Fortanix Data Security Manager (DSM)
-
-[role="_abstract"]
-To prepare Fortanix Data Security Manager (DSM) for use with the Record Encryption filter, use the following setup:
-
-* Establish a naming convention for keys and choose a Fortanix group where the keys will reside.
-* Create an application identity, with an API key, for the Record Encryption filter.
-* Create Fortanix DSM keys.
-
-include::../modules/record-encryption/fortanix-dsm/con-fortanix-dsm-setup.adoc[leveloffset=+1]
-include::../modules/record-encryption/fortanix-dsm/con-fortanix-dsm-key-creation.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-hashicorp-vault.adoc b/docs/v0.13.0/_files/assemblies/assembly-hashicorp-vault.adoc
deleted file mode 100644
index b8ca80d7..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-hashicorp-vault.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// file included in the following:
-//
-// assembly-record-encryption-filter.adoc
-
-[id='assembly-hashicorp-vault-{context}']
-= Preparing HashiCorp Vault
-
-[role="_abstract"]
-To use HashiCorp Vault with the Record Encryption filter, use the following setup:
-
-* Enable the Transit Engine as the Record Encryption filter relies on its APIs.
-* Create a Vault policy specifically for the filter with permissions for generating and decrypting Data Encryption Keys (DEKs) for envelope encryption.
-* Obtain a Vault token that includes the filter policy.
-
-include::../modules/record-encryption/hashicorp-vault/con-vault-setup.adoc[leveloffset=+1]
-
-include::../modules/record-encryption/hashicorp-vault/con-vault-key-creation.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-monitoring-record-encryption-filter.adoc b/docs/v0.13.0/_files/assemblies/assembly-monitoring-record-encryption-filter.adoc
deleted file mode 100644
index ba44ed68..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-monitoring-record-encryption-filter.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-// file included in the following:
-//
-// record-encryption-guide/index.adoc
-
-[id='assembly-monitoring-record-encryption-filter-{context}']
-= Monitoring the Record Encryption filter
-
-[role="_abstract"]
-This section describes how to monitor the Record Encryption filter.
-
-include::../modules/record-encryption/con-metrics.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-multi-tenancy-filter.adoc b/docs/v0.13.0/_files/assemblies/assembly-multi-tenancy-filter.adoc
deleted file mode 100644
index 86e1a634..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-multi-tenancy-filter.adoc
+++ /dev/null
@@ -1,31 +0,0 @@
-// file included in the following:
-//
-// assembly-built-in-filters.adoc
-
-[id='assembly-multi-tenancy-filter-{context}']
-= (Preview) Multi-tenancy filter
-
-[role="_abstract"]
-Kroxylicious’s Multi-tenancy filter presents a single Kafka cluster to tenants as if it were multiple clusters.
-Operations are isolated to a single tenant by prefixing resources with an identifier.
-
-NOTE: This filter is currently in incubation and available as a preview.
-We would not recommend using it in a production environment.
-
-The Multi-tenancy filter works by intercepting all Kafka RPCs (remote procedure calls) that reference resources, such as topic names and consumer group names:
-
-Request path:: On the request path, resource names are prefixed with a tenant identifier.
-Response path:: On the response path, the prefix is removed.
-
-Kafka RPCs that list resources are filtered so that only resources belonging to the tenant are returned, effectively creating a private cluster experience for each tenant.
-
-To set up the filter, configure it in Kroxylicious.
-
-IMPORTANT: While the Multi-tenancy filter isolates operations on resources, it does not isolate user identities across tenants.
-User authentication and ACLs (Access Control Lists) are shared across all tenants, meaning that identity is not scoped to individual tenants.
-For more information on open issues related to this filter, see {github-issues}[Kroxylicious issues^].
-
-NOTE: For more information on Kafka's support for multi-tenancy, see the {ApacheKafkaSite}.
-
-//configuring the multi-tenancy filter
-include::../modules/multi-tenancy/proc-multi-tenancy.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operations-record-encryption-filter.adoc b/docs/v0.13.0/_files/assemblies/assembly-operations-record-encryption-filter.adoc
deleted file mode 100644
index 752e2ae3..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operations-record-encryption-filter.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='assembly-operations-record-encryption-filter-{context}']
-= Operations
-
-[role="_abstract"]
-
-This section documents the operational aspects of using the record encryption filter.
-
-include::../../modules/record-encryption/con-lost-kek.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-api.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-api.adoc
deleted file mode 100644
index 3ad0ed68..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-api.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='assembly-operator-api-{context}']
-= API concepts
-
-== API resources used by the Kroxylicious Proxy
-
-The operator takes these custom resources and core Kubernetes resources as inputs:
-
-`KafkaProxy`::
-Defines an instance of the proxy.
-`VirtualKafkaCluster`::
-Represents a logical Kafka cluster that will be exposed to Kafka clients.
-`KafkaProxyIngress`::
-Configures how a virtual cluster is exposed on the network to Kafka clients.
-`KafkaService`::
-Specifies a _backend_ Kafka cluster for a virtual cluster.
-`KafkaProtocolFilter`::
-Specifies filter mechanisms for use with a virtual cluster.
-`Secret`::
-`KafkaService` and `KafkaProtocolFilter` resources may reference a `Secret` to provide security-sensitive data such as TLS certificates or passwords.
-`ConfigMap`::
-`KafkaService` and `KafkaProtocolFilter` resources may reference a `ConfigMap` to provide non-sensitive configuration such as trusted CA certificates.
-
-.Example input resources, and the references between them.
-image::operator-input-resource-topology.svg["Diagram showing the input resources, KafkaProxy, VirtualKafkaCluster, etc, as boxes, connected by arrows representing the references between the resources."]
-
-Based on the input resources just described, the operator generates the core Kubernetes resources needed to deploy the Kroxylicious proxy, such as:
-
-`ConfigMap`:: Provides the proxy configuration file mounted into the proxy container.
-`Deployment`:: Manages the proxy `Pod` and container.
-`Service`:: Exposes the proxy over the network to other workloads in the same Kubernetes cluster.
-
-The API is decomposed into multiple custom resources in a similar way to the Kubernetes Gateway API, and for similar reasons.
-You can make use of Kubernete's Role-Based Access Control (RBAC) to divide responsibility for different aspects of the overall proxy functionality to different roles (people) in your organization.
-
-For example, you might grant networking engineers the ability to configure `KafkaProxy` and `KafkaProxyIngress`, while giving application developers the ability to configure `VirtualKafkaCluster`, `KafkaService`, and `KafkaProtocolFilter` resources.
-
-.The generated Kubernetes resources, and the relationships between them
-image::operator-output-resource-topology.svg["Diagram showing the output resources, Deployment, Pod, ConfigMap, Service, with arrows showing the Deployment managing the Pod, the Pod mounting the ConfigMap, and the Service selecting the Pod."]
-
-include::../modules/con-api-compatability-operator.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-configuring-kafkaprotocolfilters.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-configuring-kafkaprotocolfilters.adoc
deleted file mode 100644
index d8aa73c6..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-configuring-kafkaprotocolfilters.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-deploy-a-proxy.adoc
-
-[id='assembly-configuring-kafkaprotocolfilters-{context}']
-= Filters
-
-[role="_abstract"]
-A `KafkaProtocolFilter` resource represents a Kroxylicious Proxy filter.
-It is not uniquely associated with a `VirtualKafkaCluster` or `KafkaProxy` instance; it can be used in a number of `VirtualKafkaCluster` instances in the same namespace.
-
-A `KafkaProtocolFilter` is similar to one of the items in a proxy configuration's `filterDefinitions`:
-
-* The resource's `metadata.name` corresponds directly to the `name` of a `filterDefinitions` item.
-* The resource's `spec.type` corresponds directly to the `type` of a `filterDefinitions` item.
-* The resource's `spec.configTemplate` corresponds to the `config` of a `filterDefinitions` item, but is subject to interpolation by the operator.
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-deploy-a-proxy.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-deploy-a-proxy.adoc
deleted file mode 100644
index 66bce15a..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-deploy-a-proxy.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-
-[id='assembly-operator-deploying-a-proxy-{context}']
-= Deploying a proxy
-
-[role="_abstract"]
-Deploy a basic proxy instance with a single virtual cluster exposed to Kafka clients on the same Kubernetes cluster.
-
-== Prerequisites
-
-* The operator must be installed in the Kubernetes cluster
-* A Kafka cluster to be proxied
-
-== The required resources
-
-include::../modules/configuring/con-kafkaproxy.adoc[leveloffset=+2]
-
-include::../modules/configuring/con-kafkaproxyingress-for-on-cluster-access.adoc[leveloffset=+2]
-
-include::../modules/configuring/con-kafkaservice-by-bootstrap.adoc[leveloffset=+2]
-
-include::../modules/configuring/con-virtualkafkacluster-tcp.adoc[leveloffset=+2]
-
-// TODO
-// == Deploying the example proxy
-//
-// include::../modules/configuring/proc-deploying-example-proxy.adoc[leveloffset=+1]
-//
-
-// configuring filters
-include::assembly-operator-configuring-kafkaprotocolfilters.adoc[leveloffset=+1]
-
-// TODO
-// == Configuring a filter
-//
-// include::../modules/configuring/proc-configuring-filter.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-install.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-install.adoc
deleted file mode 100644
index b95163c3..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-install.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='assembly-installing-{context}']
-= Installing the operator
-
-This section provides instructions for installing the Kroxylicious Operator.
-
-Installation options and procedures are demonstrated using the example files included with Kroxylicious.
-
-include::../modules/install/con-install-prereqs.adoc[leveloffset=+1]
-include::../modules/install/con-install-product-downloads.adoc[leveloffset=+1]
-include::../modules/install/proc-install-operator.adoc[leveloffset=+1]
-
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-monitoring.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-monitoring.adoc
deleted file mode 100644
index 2ac8fe63..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-monitoring.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='assembly-operator-monitoring-{context}']
-= Monitoring
-
-[role="_abstract"]
-
-Kroxylicious supports key observability features to help you understand the performance and health of your proxy instances.
-
-The Kroxylicious Proxy and Kroxylicious Operator generate metrics for real-time monitoring and alerting, as well as logs that capture their actions and behavior.
-You can integrate these metrics with a monitoring system like Prometheus for ingestion and analysis, while configuring log levels to control the granularity of logged information.
-
-include::../modules/monitoring/con-prometheus-metrics-proxy.adoc[leveloffset=+1]
-include::../modules/monitoring/con-prometheus-metrics-operator.adoc[leveloffset=+1]
-include::../modules/monitoring/con-{guide}-ingesting-metrics.adoc[leveloffset=+1]
-include::../modules/monitoring/con-{guide}-setting-log-levels.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-operate-proxy.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-operate-proxy.adoc
deleted file mode 100644
index 1e21ccea..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-operate-proxy.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='assembly-operator-operate-proxy-{context}']
-= Operating a proxy
-
-[role="_abstract"]
-Operate a deployed proxy by configuring its resource allocations.
-
-This section assumes you have a running Kroxylicious proxy instance.
-
-include::../modules/configuring/con-kafkaproxy-cpu-memory-allocation.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-overview.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-overview.adoc
deleted file mode 100644
index 3deee355..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-overview.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='assembly-overview-{context}']
-= Kroxylicious Operator overview
-
-[role="_abstract"]
-Kroxylicious Proxy is an Apache Kafka protocol-aware ("Layer 7") proxy designed to enhance Kafka-based systems.
-
-The Kroxylicious Operator is an _operator_ for Kubernetes which simplifies deploying and operating the Kroxylicious Proxy.
-
-[role="_additional-resources"]
-.Additional resources
-
-* {KubernetesSite}
-* {OperatorPattern}
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-client-proxy-connection.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-secure-client-proxy-connection.adoc
deleted file mode 100644
index 1515a69d..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-client-proxy-connection.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy.adoc
-
-[id='assembly-operator-secure-client-proxy-connection-{context}']
-= Securing the client-to-proxy connection
-
-[role="_abstract"]
-Secure client-to-proxy communications using TLS.
-
-include::../modules/configuring/con-configuring-tls-between-client-and-proxy.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-virtualkafkacluster-mtls.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-virtualkafkacluster-tls-protocol.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-virtualkafkacluster-tls-cipher.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-filter.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-secure-filter.adoc
deleted file mode 100644
index 9cbf9b2b..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-filter.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy.adoc
-
-[id='assembly-operator-secure-filter-{context}']
-= Securing filters
-
-[role="_abstract"]
-Secure filters by using the security features provided by each filter and storing sensitive values in external resources such as a Kubernetes `Secret`.
-
-include::../modules/configuring/con-kafkaprotocolfilter-secrets.adoc[leveloffset=+1]
-
-// TODO securing the encryption filter
-
-// TODO securing the validation filter
-
-// TODO securing 3rd party filters
-
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-proxy-broker-connection.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-secure-proxy-broker-connection.adoc
deleted file mode 100644
index 77abf62f..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-proxy-broker-connection.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy.adoc
-
-[id='assembly-operator-secure-proxy-broker-connection-{context}']
-= Securing the proxy-to-broker connection
-
-[role="_abstract"]
-Secure proxy-to-broker communication using TLS.
-
-include::../modules/configuring/con-configuring-kafkaservice-trust.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-tls-auth-to-kafka-cluster.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-configuring-kafkaservice-protocol.adoc[leveloffset=+1]
-
-include::../modules/configuring/con-configuring-kafkaservice-cipher.adoc[leveloffset=+1]
-
diff --git a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-proxy.adoc b/docs/v0.13.0/_files/assemblies/assembly-operator-secure-proxy.adoc
deleted file mode 100644
index 82b0752e..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-operator-secure-proxy.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-ifdef::context[:parent-context: {context}]
-:context: securing
-
-[id='assembly-operator-secure-proxy-{context}']
-= Securing a proxy
-
-[role="_abstract"]
-Secure proxies by using TLS and storing sensitive values in external resources.
-
-== Prerequisites
-
-* A running Kroxylicious proxy instance
-
-include::assembly-operator-secure-client-proxy-connection.adoc[leveloffset=+1]
-
-include::assembly-operator-secure-proxy-broker-connection.adoc[leveloffset=+1]
-
-include::assembly-operator-secure-filter.adoc[leveloffset=+1]
-
-ifdef::parent-context[:context: {parent-context}]
-ifndef::parent-context[:!context:]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-preparing-kms.adoc b/docs/v0.13.0/_files/assemblies/assembly-preparing-kms.adoc
deleted file mode 100644
index 9f91fcb9..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-preparing-kms.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-// record-encryption-guide/index.adoc
-
-= Preparing your KMS
-
-[role="_abstract"]
-This section assumes that you already have a supported KMS instance up and running.
-It describes how to prepare the KMS for use with the filter.
-
-//setting up hashicorp vault
-include::assembly-hashicorp-vault.adoc[leveloffset=+1]
-//setting up AWS KMS
-include::assembly-aws-kms.adoc[leveloffset=+1]
-ifdef::include-fortanix-dsm-kms[]
-include::assembly-fortanix-dsm.adoc[leveloffset=+1]
-endif::[]
-
diff --git a/docs/v0.13.0/_files/assemblies/assembly-proxy-monitoring.adoc b/docs/v0.13.0/_files/assemblies/assembly-proxy-monitoring.adoc
deleted file mode 100644
index 8880ce5a..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-proxy-monitoring.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-proxy/index.adoc
-
-[id='assembly-proxy-monitoring-{context}']
-= Monitoring proxies
-
-[role="_abstract"]
-
-Kroxylicious supports key observability features to help you understand the performance and health of your proxy instances.
-
-The Kroxylicious Proxy supports real-time monitoring and alerting by emitting system metrics.
-You can configure metric emission within the proxy and integrate it with a monitoring system like Prometheus to ingest and analyze the data.
-
-The Kroxylicious Proxy writes a log so that its actions may be understood over time.
-You can adjust log levels and customize logging as described in this section.
-
-include::../modules/monitoring/proc-proxy-introducing-metrics.adoc[leveloffset=+1]
-include::../modules/monitoring/con-prometheus-metrics-proxy.adoc[leveloffset=+1]
-include::../modules/monitoring/con-{guide}-ingesting-metrics.adoc[leveloffset=+1]
-include::../modules/monitoring/con-{guide}-integrating-micrometer.adoc[leveloffset=+1]
-include::../modules/monitoring/proc-{guide}-setting-log-levels.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/assemblies/assembly-proxy-overview.adoc b/docs/v0.13.0/_files/assemblies/assembly-proxy-overview.adoc
deleted file mode 100644
index 6c614968..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-proxy-overview.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-proxy/index.adoc
-// developer-guide/index.adoc
-
-[id='assembly-overview-{context}']
-= Kroxylicious Proxy overview
-
-[role="_abstract"]
-Kroxylicious is an Apache Kafka protocol-aware ("Layer 7") proxy designed to enhance Kafka-based systems.
-Through its filter mechanism it allows additional behavior to be introduced into a Kafka-based system without requiring changes to either your applications or the Kafka cluster itself.
-Built-in filters are provided as part of the solution.
-
-Functioning as an intermediary, the Kroxylicious mediates communication between a Kafka cluster and its clients.
-It takes on the responsibility of receiving, filtering, and forwarding messages.
-
-A Java API provides a convenient means for implementing custom logic within the proxy.
-
-[role="_additional-resources"]
-.Additional resources
-
-* {ApacheKafkaSite}
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/assemblies/assembly-record-validation-filter.adoc b/docs/v0.13.0/_files/assemblies/assembly-record-validation-filter.adoc
deleted file mode 100644
index df14e11b..00000000
--- a/docs/v0.13.0/_files/assemblies/assembly-record-validation-filter.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-// file included in the following:
-//
-// assembly-built-in-filters.adoc
-
-[id='assembly-record-validation-filter-{context}']
-= (Preview) Record Validation filter
-
-[role="_abstract"]
-The Record Validation filter validates records sent by a producer.
-Only records that pass the validation are sent to the broker.
-This filter can be used to prevent _poison messages_—such as those containing corrupted data or invalid formats—from entering the Kafka system, which may otherwise lead to consumer failure.
-
-The filter currently supports two modes of operation:
-
-1. Schema Validation ensures the content of the record conforms to a schema stored in an https://www.apicur.io/registry/[Apicurio Registry].
-2. JSON Syntax Validation ensures the content of the record contains syntactically valid JSON.
-
-Validation rules can be applied to check the content of the Kafka record key or value.
-
-If the validation fails, the product request is rejected and the producing application receives an error response. The broker
-will not receive the rejected records.
-
-NOTE: This filter is currently in incubation and available as a preview.
-We would not recommend using it in a production environment.
-
-//configuring the record-validation filter
-include::../modules/record-validation/proc-record-validation.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/developer-guide/_assets b/docs/v0.13.0/_files/developer-guide/_assets
deleted file mode 120000
index f6c9582d..00000000
--- a/docs/v0.13.0/_files/developer-guide/_assets
+++ /dev/null
@@ -1 +0,0 @@
-../_assets
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/developer-guide/assemblies b/docs/v0.13.0/_files/developer-guide/assemblies
deleted file mode 120000
index ff41b88e..00000000
--- a/docs/v0.13.0/_files/developer-guide/assemblies
+++ /dev/null
@@ -1 +0,0 @@
-../assemblies
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/developer-guide/index.adoc b/docs/v0.13.0/_files/developer-guide/index.adoc
deleted file mode 100644
index 0d94971d..00000000
--- a/docs/v0.13.0/_files/developer-guide/index.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-:experimental:
-include::_assets/attributes.adoc[]
-
-:context: proxy
-:guide: developer
-
-[id="using-book-{context}"]
-= Kroxylicious Developer guide
-
-include::modules/con-about-{guide}-guide.adoc[leveloffset=+1]
-
-include::assemblies/assembly-proxy-overview.adoc[leveloffset=+1]
-
-include::modules/con-api-compatability-{guide}.adoc[leveloffset=+2]
-
-include::modules/con-custom-filters.adoc[leveloffset=+1]
-
-//trademark notices
-include::_assets/trademarks.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/developer-guide/modules b/docs/v0.13.0/_files/developer-guide/modules
deleted file mode 120000
index 464b823a..00000000
--- a/docs/v0.13.0/_files/developer-guide/modules
+++ /dev/null
@@ -1 +0,0 @@
-../modules
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/index.adoc b/docs/v0.13.0/_files/index.adoc
deleted file mode 100644
index dc4e189f..00000000
--- a/docs/v0.13.0/_files/index.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-:DocRoot: .
-include::_assets/attributes.adoc[]
-
-= Kroxylicious guides
-
-This release of Kroxylicious is documented in the following guides:
-
-{ProxyGuide}:: Covers using the proxy, including configuration, security and operation.
-
-{OperatorGuide}:: Covers using the Kubernetes operator for the proxy, including configuration, security and operation.
-
-{RecordEncryptionGuide}:: Covers using the record encryption filter, including configuration, security and operation.
-
-{DeveloperGuide}:: Covers writing plugins for the proxy in the Java programming language
diff --git a/docs/v0.13.0/_files/kroxylicious-operator/_assets b/docs/v0.13.0/_files/kroxylicious-operator/_assets
deleted file mode 120000
index f6c9582d..00000000
--- a/docs/v0.13.0/_files/kroxylicious-operator/_assets
+++ /dev/null
@@ -1 +0,0 @@
-../_assets
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-operator/assemblies b/docs/v0.13.0/_files/kroxylicious-operator/assemblies
deleted file mode 120000
index ff41b88e..00000000
--- a/docs/v0.13.0/_files/kroxylicious-operator/assemblies
+++ /dev/null
@@ -1 +0,0 @@
-../assemblies
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-operator/index.adoc b/docs/v0.13.0/_files/kroxylicious-operator/index.adoc
deleted file mode 100644
index 86b37798..00000000
--- a/docs/v0.13.0/_files/kroxylicious-operator/index.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-:experimental:
-include::_assets/attributes.adoc[]
-
-:context: operator
-:guide: operator
-
-[id="using-book-{context}"]
-= Kroxylicious Operator for Kubernetes
-
-include::modules/con-about-{guide}-guide.adoc[leveloffset=+2]
-
-include::assemblies/assembly-operator-overview.adoc[leveloffset=+1]
-
-include::assemblies/assembly-operator-api.adoc[leveloffset=+1]
-
-// installing
-include::assemblies/assembly-operator-install.adoc[leveloffset=+1]
-
-// TODO upgrade the operator
-// include::assemblies/assembly-operator-api.adoc[leveloffset=+1]
-
-// deploy a proxy
-include::assemblies/assembly-operator-deploy-a-proxy.adoc[leveloffset=+1]
-
-// operating proxies
-include::assemblies/assembly-operator-operate-proxy.adoc[leveloffset=+1]
-
-// securing proxies
-include::assemblies/assembly-operator-secure-proxy.adoc[leveloffset=+1]
-
-// // monitoring proxies
-include::assemblies/assembly-operator-monitoring.adoc[leveloffset=+1]
-
-include::modules/ref-glossary.adoc[leveloffset=+1]
-
-//trademark notices
-include::_assets/trademarks.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-operator/modules b/docs/v0.13.0/_files/kroxylicious-operator/modules
deleted file mode 120000
index 464b823a..00000000
--- a/docs/v0.13.0/_files/kroxylicious-operator/modules
+++ /dev/null
@@ -1 +0,0 @@
-../modules
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-operator/snippets b/docs/v0.13.0/_files/kroxylicious-operator/snippets
deleted file mode 120000
index 9d58b92e..00000000
--- a/docs/v0.13.0/_files/kroxylicious-operator/snippets
+++ /dev/null
@@ -1 +0,0 @@
-../snippets/
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-proxy/_assets b/docs/v0.13.0/_files/kroxylicious-proxy/_assets
deleted file mode 120000
index f6c9582d..00000000
--- a/docs/v0.13.0/_files/kroxylicious-proxy/_assets
+++ /dev/null
@@ -1 +0,0 @@
-../_assets
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-proxy/assemblies b/docs/v0.13.0/_files/kroxylicious-proxy/assemblies
deleted file mode 120000
index ff41b88e..00000000
--- a/docs/v0.13.0/_files/kroxylicious-proxy/assemblies
+++ /dev/null
@@ -1 +0,0 @@
-../assemblies
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-proxy/index.adoc b/docs/v0.13.0/_files/kroxylicious-proxy/index.adoc
deleted file mode 100644
index ac0a33bb..00000000
--- a/docs/v0.13.0/_files/kroxylicious-proxy/index.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-:experimental:
-include::_assets/attributes.adoc[]
-
-:context: proxy
-:guide: proxy
-
-[id="using-book-{context}"]
-= Kroxylicious Proxy
-
-include::modules/con-about-{guide}-guide.adoc[leveloffset=+1]
-
-include::assemblies/assembly-proxy-overview.adoc[leveloffset=+1]
-//broker config
-include::modules/con-proxy-overview.adoc[leveloffset=+2]
-include::modules/con-api-compatability-{guide}.adoc[leveloffset=+2]
-
-//configuring
-include::assemblies/assembly-configuring-proxy.adoc[leveloffset=+1]
-
-//built-in filters
-include::assemblies/assembly-built-in-filters.adoc[leveloffset=+1]
-
-//community filters
-include::modules/con-community-filters.adoc[leveloffset=+1]
-
-//monitoring
-include::assemblies/assembly-{guide}-monitoring.adoc[leveloffset=+1]
-
-//trademark notices
-include::_assets/trademarks.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/kroxylicious-proxy/modules b/docs/v0.13.0/_files/kroxylicious-proxy/modules
deleted file mode 120000
index 464b823a..00000000
--- a/docs/v0.13.0/_files/kroxylicious-proxy/modules
+++ /dev/null
@@ -1 +0,0 @@
-../modules
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-about-developer-guide.adoc b/docs/v0.13.0/_files/modules/con-about-developer-guide.adoc
deleted file mode 100644
index 4ed82705..00000000
--- a/docs/v0.13.0/_files/modules/con-about-developer-guide.adoc
+++ /dev/null
@@ -1,5 +0,0 @@
-[discrete]
-= About this guide
-
-This guide covers developing plugins for Kroxylicious using the Java programming language.
-Other guides should be consulted if you want to deploy, configure or secure a Kroxylicious proxy.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-about-operator-guide.adoc b/docs/v0.13.0/_files/modules/con-about-operator-guide.adoc
deleted file mode 100644
index ca41873b..00000000
--- a/docs/v0.13.0/_files/modules/con-about-operator-guide.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
-
-[discrete]
-= About this guide
-
-This guide covers using the *Kroxylicious Operator* to configure, deploy, secure, and operate the Kroxylicious proxy on Kubernetes.
-Refer to other Kroxylicious guides for information on running the proxy outside Kubernetes or for advanced topics such as plugin development.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-about-proxy-guide.adoc b/docs/v0.13.0/_files/modules/con-about-proxy-guide.adoc
deleted file mode 100644
index b40d6af6..00000000
--- a/docs/v0.13.0/_files/modules/con-about-proxy-guide.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
-
-[discrete]
-= About this guide
-
-This guide covers installing, configuring, securing, and operating the Kroxylicious Proxy in a non-Kubernetes environment.
-Refer to other Kroxylicious guides for information on running the proxy on Kubernetes using the Kroxylicious Operator, or for advanced topics such as plugin development.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-api-compatability-developer.adoc b/docs/v0.13.0/_files/modules/con-api-compatability-developer.adoc
deleted file mode 100644
index 4c90b733..00000000
--- a/docs/v0.13.0/_files/modules/con-api-compatability-developer.adoc
+++ /dev/null
@@ -1,26 +0,0 @@
-// Module included in the following:
-//
-// assembly-proxy-overview.adoc
-
-[id='con-api-compatibility{context}']
-= Compatibility
-
-There are effectively two APIs a filter developer needs to care about:
-
-. The Filter API against which the filter is written.
-This is a contract between the Filter developer and the Kroxylicious runtime. It includes `Filter`, `FilterFactory`, which the developer is responsible for implementing, and `FilterContext` and `FilterFactoryContext`, which are provided by the Kroxylicous runtime for the developer to use.
-. The "configuration API" that your filter exposes. This is a contract between the Filter developer and Kroxylicious users.
-
-== Compatibility of the Filter API
-
-The Kroxylicious project uses semantic versioning.
-For the filter API this means that you can compile your filter against the Kroxylicious API at version _x.y~c~.z~c~_ and users will be able to use it with Kroxylicious runtimes at version _x.y~r~.z~r~_ if the runtime version is not older than the compile time version (that is if _y~r~_ ≥ _y~c~_ and _z~r~_ ≥ _z~c~_).
-
-== Compatibility of your Filter configuration
-
-The Kroxylicious proxy isn't able to provide or enforce any compatibility guarantees about the configuration API that your plugin offers to users.
-In other words you are free you release your plugin at version _a.b.c_ and later release a version _a.d.e_ which doesn't accept the same configuration syntax (JSON or YAML) that the original version did.
-
-Doing this makes it more difficult for users to upgrade from older versions on your plugin, because they will have to rewrite and revalidate the configuration which worked with the old version.
-
-For this reason filter developers are strongly encouraged to adopt Semantic versioning as the way to communicate compatibility of the configuration API they offer to users.
diff --git a/docs/v0.13.0/_files/modules/con-api-compatability-operator.adoc b/docs/v0.13.0/_files/modules/con-api-compatability-operator.adoc
deleted file mode 100644
index f76a2b02..00000000
--- a/docs/v0.13.0/_files/modules/con-api-compatability-operator.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-// Module included in the following:
-//
-// assembly-proxy-overview.adoc
-
-[id='con-api-compatibility{context}']
-= Compatibility
-
-[id='con-api-compatibility-api{context}']
-== Custom resource APIs
-
-Kroxylicious custom resource definitions are packaged and deployed alongside the operator. Currently, there's only a single version of the custom resource APIs: `v1alpha1`.
-
-Future updates to the operator may introduce new versions of the custom resource APIs. At that time the operator will be backwards compatible with older versions of those APIs and an upgrade procedure will be used to upgrade existing custom resources to the new API version.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-api-compatability-proxy.adoc b/docs/v0.13.0/_files/modules/con-api-compatability-proxy.adoc
deleted file mode 100644
index 6873dfe7..00000000
--- a/docs/v0.13.0/_files/modules/con-api-compatability-proxy.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-// Module included in the following:
-//
-// assembly-proxy-overview.adoc
-
-[id='con-api-compatibility{context}']
-= Compatibility
-
-[id='con-api-compatibility-api{context}']
-== APIs
-
-Kroxylicious follows https://semver.org/#semantic-versioning-200[Semantic Versioning] rules. While we are still in the initial development phase ({unstable-api-version}), we still take API compatibility very seriously. We aim to provide at least two minor releases between deprecation and the removal of that deprecated item.
-
-We also consider our configuration file syntax a public API (though not the Java model backing it). As such, the syntax follows the same Semantic Versioning and deprecation rules.
-
-Kubernetes custom resources are a public API, and we are making every effort to evolve Kroxylicious custom resources in line with https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/[Kubernetes best practices]. Kubernetes resources have their own versioning scheme, which is independent of the Kroxylicious proxy service version. As a result, we may reach {stable-api-version} of Kroxylicious while still using alpha or beta versions of the custom resources.
-
-[id='con-api-compatibility-third-party{context}']
-=== Third-party plugins
-
-Kroxylicious supports loading third-party plugins to extend the core functionality of the project. While these plugins are configured and loaded as first-class entities within Kroxylicious, we cannot guarantee the compatibility of their APIs or configuration properties.
-
-We do however hold filters and plugins provided by the project to the same standards as the rest of the public API.
-
-[id='con-api-compatibility-wire-protocol{context}']
-== Wire protocol
-
-Kroxylicious offers the same backwards and forwards compatibility guarantees as https://kafka.apache.org/protocol#protocol_compatibility[Apache Kafka]. We support the same range of client and broker versions as the official Apache Kafka Java client.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-community-filters.adoc b/docs/v0.13.0/_files/modules/con-community-filters.adoc
deleted file mode 100644
index ab3c5a5b..00000000
--- a/docs/v0.13.0/_files/modules/con-community-filters.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-proxy/index.adoc
-
-[id='con-community-filters-{context}']
-= Community filters
-
-[role="_abstract"]
-Community contributed filters are showcased in the
-https://github.com/kroxylicious/kroxylicious-community-gallery[Community Gallery^].
-
-NOTE: These filters are contributed by the community and are not managed or maintained by the Kroxylicious team.
-Use them at your own risk.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-custom-filters.adoc b/docs/v0.13.0/_files/modules/con-custom-filters.adoc
deleted file mode 100644
index 674946d9..00000000
--- a/docs/v0.13.0/_files/modules/con-custom-filters.adoc
+++ /dev/null
@@ -1,488 +0,0 @@
-// Assembly included in the following:
-//
-// kroxylicious-proxy/index.adoc
-
-[id='con-custom-filters-{context}']
-= Custom filters
-
-[role="_abstract"]
-Custom filters can be written in the Java programming language.
-Kroxylicious supports Java 17.
-Knowledge of the {kafka-protocol}[Kafka protocol^] is generally required to write a protocol filter.
-
-There is currently one class of Custom Filters users can implement:
-
-<>:: Allow customisation of how protocol messages are handled on their way to, or from, the Cluster.
-
-The following sections explain in more detail how to write your own filters.
-
-== Sample Custom Filter Project
-
-A collection of sample filters is available within the Kroxylicious repository for you to download, try out, and customise.
-You can find them {github}/tree/main/kroxylicious-sample[here] for a hands-on introduction to creating your own custom filters.
-
-== API docs
-
-Custom filters are built by implementing interfaces supplied by the
-{github}/tree/main/kroxylicious-api[kroxylicious-api^] module
-(https://mvnrepository.com/artifact/io.kroxylicious/kroxylicious-api[io.kroxylicious:kroxylicious-api] on
-maven central). You can view the javadoc {api-javadoc}/io/kroxylicious/proxy/filter/package-summary.html[here^].
-
-== Dependencies
-
-How filter classes are loaded is not currently defined by the filter contract.
-In other words, filters might be loaded using a classloader-per-filter model,
-or using a single class loader.
-This doesn't really make a difference to filter authors except where they want to make use of libraries as dependencies.
-Because those dependencies might be loaded by the same classloader as the dependencies of other filters there is the possibility of collision. Filter A and Filter B might both want to use Library C, and they might want to use different versions of Library C.
-
-For common things like logging and metric facade APIs it is recommended to use the facade APIs which are also used by the proxy core.
-
-// TODO Maven dependency
-// TODO Gradle dependency
-
-// TODO recommend BOM usage
-
-== Protocol filters
-
-A protocol filter is a `public` top-level, concrete class with a particular public constructor and which implements
-one or more protocol filter interfaces. You can implement two distinct types of Custom Protocol Filter:
-
-- <>
-- <>
-
-Note that these types are mutually exclusive, for example a Filter is not allowed to implement both `RequestFilter` and
-`MetadataRequestFilter`. This is to prevent ambiguity. If we received a `MetadataRequest`, would it be dispatched to
-the `onMetadataRequest(..)` method of `MetadataRequestFilter` or the `onRequest` method of `RequestFilter`, or both?
-Instead, we disallow these combinations, throwing an exception at runtime if your Filter implements incompatible interfaces.
-
-=== Specific Message Protocol Filters
-
-A filter may wish to intercept specific types of Kafka messages. For example, intercept all Produce Requests, or
-intercept all Fetch Responses. To support this case Kroxylicious provides an interfaces for all request types and
-response types supported by Kafka (at the version of Kafka Kroxylicious depends on). A filter implementation can
-implement any combination of these interfaces.
-
-There is no requirement that a Filter handles both the request and response halves of an RPC. A Filter can choose to
-intercept only the request, or only the response, or both the request and response.
-
-==== Examples
-
-To intercept all Fetch Requests your class would implement
-{api-javadoc}/io/kroxylicious/proxy/filter/FetchRequestFilter.html[FetchRequestFilter^]:
-
-[source,java]
-----
-public class FetchRequestClientIdFilter implements FetchRequestFilter {
-
- @Override
- public CompletionStage onFetchRequest(short apiVersion,
- RequestHeaderData header,
- FetchRequestData request,
- FilterContext context) {
- header.setClientId("fetch-client!");
- return context.forwardRequest(header, request);
- }
-}
-----
-
-To intercept all Fetch Responses your class would implement
-{api-javadoc}/io/kroxylicious/proxy/filter/FetchResponseFilter.html[FetchResponseFilter^]:
-
-[source,java]
-----
-public class FetchRequestClientIdFilter implements FetchResponseFilter {
-
- @Override
- public CompletionStage onFetchResponse(short apiVersion,
- ResponseHeaderData header,
- FetchResponseData response,
- FilterContext context) {
- mutateResponse(response);
- return context.forwardResponse(header, response);
- }
-}
-----
-
-To intercept all Fetch Requests and all Fetch Responses your class would implement
-{api-javadoc}/io/kroxylicious/proxy/filter/FetchRequestFilter.html[FetchRequestFilter^] and
-{api-javadoc}/io/kroxylicious/proxy/filter/FetchResponseFilter.html[FetchResponseFilter^]:
-
-[source,java]
-----
-public class FetchRequestClientIdFilter implements FetchRequestFilter, FetchResponseFilter {
-
- @Override
- public CompletionStage onFetchRequest(short apiVersion,
- RequestHeaderData header,
- FetchRequestData request,
- FilterContext context) {
- header.setClientId("fetch-client!");
- return context.forwardRequest(header, request);
- }
-
- @Override
- public CompletionStage onFetchResponse(short apiVersion,
- ResponseHeaderData header,
- FetchResponseData response,
- FilterContext context) {
- mutateResponse(response);
- return context.forwardResponse(header, response);
- }
-}
-----
-Specific Message Filter interfaces are mutually exclusive with <>.
-Kroxylicious will reject invalid combinations of interfaces.
-
-=== Request/Response Protocol Filters
-
-A filter may wish to intercept every message being sent from the Client to the Cluster or from the Cluster
-to the Client. To do this your custom filter will implement:
-
-- {api-javadoc}/io/kroxylicious/proxy/filter/RequestFilter.html[RequestFilter^]
-to intercept all requests.
-- {api-javadoc}/io/kroxylicious/proxy/filter/ResponseFilter.html[ResponseFilter^]
-to intercept all responses.
-
-Custom filters are free to implement either interface or both interfaces to intercept all messages.
-
-For example:
-
-[source,java]
-----
-public class FixedClientIdFilter implements RequestFilter {
-
- @Override
- public CompletionStage onRequest(ApiKeys apiKey,
- RequestHeaderData header,
- ApiMessage body,
- FilterContext filterContext) {
- header.setClientId("example!");
- return filterContext.forwardRequest(header, body);
- }
-
-}
-----
-
-Request/Response Filter interfaces are mutually exclusive with <> interfaces.
-Kroxylicious will reject invalid combinations of interfaces.
-
-=== The Filter Result
-
-As seen above, filter methods (`onXyz[Request|Response]`) must return a `CompletionStage` object.
-It is the job of `FilterResult` to convey what message is to forwarded to the next filter in the chain (or broker
-/client if at the chain's beginning or end). It is also used to carry instructions such as indicating that the
-connection must be closed, or a message dropped.
-
-If the filter returns a `CompletionStage` that is already completed normally, Kroxylicious will immediately perform
-the action described by the `FilterResult`.
-
-The filter may return a `CompletionStage` that is not yet completed. When this happens, Kroxylicious will pause
-reading from the downstream (the Client writes will eventually block), and it begins to queue up in-flight
-requests/responses arriving at the filter. This is done so that message order is maintained. Once the
-`CompletionStage` completes, the action described by the `FilterResult` is performed, reading from the downstream
-resumes and any queued up requests/responses are processed.
-
-IMPORTANT: The pausing of reads from the downstream is a relatively costly operation. To maintain optimal performance
-filter implementations should minimise the occasions on which an incomplete `CompletionStage` is returned.
-
-If the `CompletionStage` completes exceptionally, the connection is closed. This also applies if the
-`CompletionStage` does not complete within a timeout (20000 milliseconds).
-
-==== Creating a Filter Result
-The `FilterContext` is the factory for the `FilterResult` objects.
-
-There are two convenience methods{empty}footnote:[The `context.forward*()` methods behave exactly as the builder form
-`.forward(header, message).complete()`] that simply allow a filter to forward a result to the next filter.
-We've already seen these in action above.
-
-* `context.forwardRequest(header, request)` used by result filter to forward a request.
-* `context.forwardResponse(header, response)` used by result filter to forward a request.
-
-To access richer features, use the filter result builders `context.requestFilterResultBuilder()` and
-`responseFilterResultBuilder()`.
-
-Filter result builders allow you to:
-
-1. forward a request/response: `.forward(header, request)`.
-2. signal that a connection is to be closed: `.withCloseConnection()`.
-3. signal that a message is to be dropped (i.e. not forwarded): `.drop()`.
-4. for requests only, send a short-circuit response: `.shortCircuitResponse(header, response)`
-
-The builder lets you combine legal behaviours together. For instance, to close the connection after forwarding
-a response to a client, a response filter could use:
-
-[source,java]
-----
-return context.responseFilterResultBuilder()
- .forward(header, response)
- .withCloseConnection()
- .complete();
-----
-
-The builders yield either a completed `CompletionStage` which can be returned directly from the
-filter method, or bare `FilterResult`. The latter exists to support asynchronous programming styles allowing you
-to use your own Futures.
-
-IMPORTANT: The `drop` behaviour can be legally used in very specific circumstances. The Kafka Protocol is,
-for the most part, strictly request/response with responses expected in the order the request were sent. The client
-will fail if the contract isn't upheld. The exception is `Produce` where `acks=0`. Filters may drop these requests without
-introducing a protocol error.
-
-=== The protocol filter lifecycle
-
-Instances of the filter class are created on demand when a protocol message is first sent by a client.
-Instances are specific to the channel between a single client and a single broker.
-
-It exists while the client remains connected.
-
-=== Handling state
-
-The simplest way of managing per-client state is to use member fields.
-The proxy guarantees that all methods of a given filter instance will always be invoked on the same thread (also true of
-the CompletionStage completion in the case of <>).
-Therefore, there is no need to use synchronization when accessing such fields.
-
-See the {api-javadoc}/io/kroxylicious/proxy/filter/package-summary.html#implementing.threadSafety[`io.kroxylicious.proxy.filter`^]
-package javadoc for more information on thread-safety.
-
-=== Filter Patterns
-
-Kroxylicious Protocol Filters support several patterns:
-
-1. <>
-2. <>
-3. <>
-4. <>
-
-==== Intercepting Requests and Responses
-
-This is a common pattern, we want to inspect or modify a message. For example:
-
-[source,java]
-----
-public class SampleFetchResponseFilter implements FetchResponseFilter {
- @Override
- public CompletionStage onFetchResponse(short apiVersion,
- ResponseHeaderData header,
- FetchResponseData response,
- FilterContext context) {
- mutateResponse(response, context); //<1>
- return context.forwardResponse(header, response); //<2>
- }
-}
-----
-<1> We mutate the response object. For example, you could alter the records that have been fetched.
-<2> We forward the response, sending it towards the client, invoking Filters downstream of this one.
-
-NOTE: We can only forward the response and header objects passed into the `onFetchResponse`. New instances are not
-supported.
-
-==== Sending Response messages from a Request Filter towards the Client (Short-circuit responses)
-
-In some cases we may wish to not forward a request from the client to the Cluster. Instead, we want to intercept that
-request and generate a response message in a Kroxylicious Protocol Filter and send it towards the client. This is called
-a short-circuit response.
-
-.Illustration of responding without proxying
-[a2s, format="svg"]
-....
-.----------------------------------------------------------------------------------------------------------------------.
-| |
-| '---------------------------------------------------------------' |
-| |[Kroxylicious] | |
-| | | |
-| | '----------------------------------------------------' | '--------------------' |
-| | |[Virtual Cluster] | | |[Cluster] | |
-| '-------------' | | '----------' '----------' '----------' | | | '------------' | |
-| |[Client] | | | |[Filter1] | |[Filter2] | |[Filter3] | | | | |[Broker] | | |
-| | |======|===|==>| |====>| | | | | | | | | | |
-| | | A | | | F(A)-->B | B | F(B)-->C | | | | | | | | | |
-| | | | | | | | : | | | | | | | | | |
-| | |<=====|===|===| |<====| : | | | | | | | | | |
-| | | W | | | f(C)-->W | C | <======+ | | | | | | | | | |
-| '-------------' | | '----------' '----------' '----------' | | | '------------' | |
-| | | | | '--------------------' |
-| | '----------------------------------------------------' | |
-| | | |
-| '---------------------------------------------------------------' |
-| |
-.----------------------------------------------------------------------------------------------------------------------.
-[0,0]: {"fill":"#99d","a2s:delref":1}
-....
-
-For example:
-
-[source,java]
-----
-public class CreateTopicRejectFilter implements CreateTopicsRequestFilter {
-
- public CompletionStage onCreateTopicsRequest(short apiVersion, RequestHeaderData header, CreateTopicsRequestData request,
- FilterContext context) {
- CreateTopicsResponseData response = new CreateTopicsResponseData();
- CreateTopicsResponseData.CreatableTopicResultCollection topics = new CreateTopicsResponseData.CreatableTopicResultCollection(); // <1>
- request.topics().forEach(creatableTopic -> {
- CreateTopicsResponseData.CreatableTopicResult result = new CreateTopicsResponseData.CreatableTopicResult();
- result.setErrorCode(Errors.INVALID_TOPIC_EXCEPTION.code()).setErrorMessage(ERROR_MESSAGE);
- result.setName(creatableTopic.name());
- topics.add(result);
- });
- response.setTopics(topics);
- return context.requestFilterResultBuilder().shortCircuitResponse(response).completed(); // <2>
- }
-}
-----
-<1> Create a new instance of the corresponding response data and populate it. Note you may need to use the `apiVersion`
-to check which fields can be set at this request's API version.
-<2> We generate a short-circuit response that will send it towards the client, invoking Filters downstream of this one.
-
-This will respond to all Create Topic requests with an error response without forwarding any of those requests to the Cluster.
-
-===== Closing the connections
-
-There is a useful variation on the pattern above, where the filter needs, in addition to sending an error
-response, also to cause the connection to close. This is useful in use-cases where the filter wishes to disallow
-certain client behaviours.
-
-[source,java]
-----
-public class DisallowAlterConfigs implements AlterConfigsRequestFilter {
-
- @Override
- public CompletionStage onAlterConfigsRequest(short apiVersion, RequestHeaderData header, AlterConfigsRequestData request,
- FilterContext context) {
- var response = new AlterConfigsResponseData();
- response.setResponses(request.resources().stream()
- .map(a -> new AlterConfigsResourceResponse()
- .setErrorCode(Errors.INVALID_CONFIG.code())
- .setErrorMessage("This service does not allow this operation - closing connection"))
- .toList());
- return context.requestFilterResultBuilder()
- .shortCircuitResponse(response)
- .withCloseConnection() // <1>
- .completed();
- }
-}
-----
-<1> We enable the close connection option on the builder. This will cause Kroxylicious to close the connection
-after the response is sent to the client.
-
-==== Sending asynchronous requests to the Cluster
-
-Filters can make additional asynchronous requests to the Cluster. This is useful if the Filter needs additional
-information from the Cluster in order to know how to mutate the filtered request/response.
-
-The Filter can make use of {java-17-javadoc}/java.base/java/util/concurrent/CompletionStage.html[CompletionStage^]
-chaining features ([`#thenApply()` etc.) to organise for actions to be done once the asynchronous request completes.
-For example, it could chain an action that mutates the filtered request/response using the asynchronous response, and
-finally, chain an action to forward the request/response to the next filter.
-
-The asynchronous request/response will be intercepted by Filters upstream of this Filter. Filters downstream of this
-Filter (and the Client) do not see the asynchronous response.
-
-Let's take a look at an example. We'll send an asynchronous request towards the Cluster for topic metadata while
-handling a FetchRequest and use the response to mutate the FetchRequest before passing it to the next filter in the chain.
-
-[source,java]
-----
-public class FetchFilter implements FetchRequestFilter {
- public static final short METADATA_VERSION_SUPPORTING_TOPIC_IDS = (short) 12;
-
- @Override
- public CompletionStage onFetchRequest(ApiKeys apiKey,
- RequestHeaderData header,
- FetchRequestData request,
- FilterContext context) {
- var metadataRequestHeader = new RequestHeaderData().setRequestApiVersion(METADATA_VERSION_SUPPORTING_TOPIC_IDS); // <1>
- var metadataRequest = new MetadataRequestData(); // <2>
- var topic = new MetadataRequestData.MetadataRequestTopic();
- topic.setTopicId(Uuid.randomUuid());
- metadataRequest.topics().add(topic);
- var stage = context.sendRequest(metadataRequestHeader, metadataRequest); // <3>
- return stage.thenApply(metadataResponse -> mutateFetchRequest(metadataResponse, request)) // <4>
- .thenCompose(mutatedFetchRequest -> context.forwardRequest(header, mutatedFetchRequest)); // <5>
- }
-}
-----
-<1> We construct a header object for the asynchronous request. It is important to specify the API version of the request
-that is to be used. The version chosen must be a version known to the Kafka Client used by Kroxylicious
-and must be an API version supported by the Target Cluster.
-<2> We construct a new request object. When constructing the request object, care needs to be taken to ensure the request is populated with the structure which matches the API version you have chosen. Refer to the {kafka-protocol}[Kafka Protocol Guide] for more details.
-<3> We asynchronously send the request towards the Cluster and obtain a CompletionStage which will contain the response.
-<4> We use a computation stage to mutate the filtered fetch request using the response from the request sent at <3>.
-<5> We use another computation stage to forward the mutated request.
-
-As you have read above, we need to know the API version we want our request to be encoded at. Your filter can discover
-what versions of an API the Kafka Cluster supports. To do this use the
-{api-javadoc}/io/kroxylicious/proxy/ApiVersionsService.html[ApiVersionsService^] available from the `FilterContext`
-to determine programmatically what versions of an API are support and then write code to make a suitable `request`
-object.
-
-NOTE: Kroxylicious provides the guarantee that computation stages chained using the _default execution methods_ are
-executed on the same thread as the rest of the Filter work, so we can safely mutate Filter members without synchronising.
-See the {api-javadoc}/io/kroxylicious/proxy/filter/package-summary.html#implementing.threadSafety[`io.kroxylicious.proxy.filter`^]
-package javadoc for more information on thread-safety.
-
-==== Filtering specific API Versions
-
-> Kafka has a "bidirectional" client compatibility policy. In other words, new clients can talk to old servers, and old clients can talk to new servers. This allows users to upgrade either clients or servers without experiencing any downtime.
->
-> Since the Kafka protocol has changed over time, clients and servers need to agree on the schema of the message that they are sending over the wire. This is done through API versioning.
->
-> Before each request is sent, the client sends the API key and the API version. These two 16-bit numbers, when taken together, uniquely identify the schema of the message to follow.
-> -- https://kafka.apache.org/protocol.html#protocol_compatibility
-
-You may wish to restrict your Filter to only apply to specific versions of an API. For example, "intercept all FetchRequest
-messages greater than api version 7". To do this you can override a method named `shouldHandleXyz[Request|Response]` on your filter like:
-
-[source,java]
-----
-public class FetchFilter implements FetchRequestFilter {
-
- @Override
- public boolean shouldHandleFetchRequest(short apiVersion) {
- return apiVersion > 7;
- }
-
- @Override
- @Override
- public CompletionStage onRequest(ApiKeys apiKey,
- RequestHeaderData header,
- ApiMessage body,
- FilterContext filterContext) {
- return context.forwardRequest(header, request);
- }
-}
-----
-
-=== Filter Construction and Configuration
-For Kroxylicious to instantiate and configure your custom filter we use Java's {java-17-javadoc}/java.base/java/util/ServiceLoader.html[ServiceLoader^] API.
-Each Custom Filter should provide a corresponding {api-javadoc}/io/kroxylicious/proxy/filter/FilterFactory.html[FilterFactory^]
-implementation that can create an instance of your custom Filter. The factory can optionally declare a configuration class that Kroxylicious will
-populate (using Jackson) when loading your custom Filter. The module must package a `META-INF/services/io.kroxylicious.proxy.filter.FilterFactory`
-file containing the classnames of each filter factory implementation into the JAR file.
-
-For example in the kroxylicious-samples we have the {github}/blob/main/kroxylicious-sample/src/main/java/io/kroxylicious/sample/config/SampleFilterConfig.java[SampleFilterConfig] class.
-This is used in the {github}/blob/main/kroxylicious-sample/src/main/java/io/kroxylicious/sample/SampleFetchResponseFilter.java[SampleFetchResponseFilter]). The configuration is routed to the Filter instance via the
-{github}/blob/main/kroxylicious-sample/src/main/java/io/kroxylicious/sample/SampleFetchResponse.java[SampleFetchResponse].
-
-Then, when we configure a filter in Kroxylicious configuration like:
-
-[source,yaml]
-----
-filterDefinitions:
-- name: my-replacer
- type: SampleFetchResponse
- config:
- findValue: a
- replacementValue: b
-----
-Kroxylicious will deserialize the `config` object into a `SampleFilterConfig` and use it to construct a
-`SampleFetchResponseFilter` passing the `SampleFilterConfig` instance as a constructor argument.
-
-== Packaging filters
-
-Filters are packaged as standard `.jar` files. A typical Custom Filter jar contains:
-
-1. Filter implementation classes
-2. A FilterFactory implementation per Filter and service metadata (see <>)
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/con-proxy-overview.adoc b/docs/v0.13.0/_files/modules/con-proxy-overview.adoc
deleted file mode 100644
index e72fc857..00000000
--- a/docs/v0.13.0/_files/modules/con-proxy-overview.adoc
+++ /dev/null
@@ -1,256 +0,0 @@
-// Module included in the following:
-//
-// assembly-proxy-overview.adoc
-
-[id='con-proxy-overview-{context}']
-= Why use proxies?
-
-Proxies are a powerful and flexible architectural pattern.
-For Kafka, they can be used to add functionality to Kafka clusters which is not available out-of-the-box with Apache Kafka.
-In an ideal world, such functionality would be implemented directly in Apache Kafka.
-But there are numerous practical reasons that can prevent this, for example:
-
-* Organizations having very niche requirements which are unsuitable for implementation directly in Apache Kafka.
-* Functionality which requires changes to Kafka's public API and which the Apache Kafka project is unwilling to implement.
- This is the case for https://lists.apache.org/thread/x1p119hkpoy01vq9ck3d0ql67jtvm875[broker interceptors], for example.
-* Experimental functionality which might end up being implemented in Apache Kafka eventually.
-For example using Kroxylicious it's easier to experiment with alternative transport protocols, such as Quic, or operating system APIs, such as io_uring, because there is already support for this in Netty, the networking framework on which Kroxylicious is built.
-
-== How Kroxylicious works
-
-First let's define the concepts in the landscape surrounding Kroxylicious.
-
-. _Kafka Client_, or _Client_ refers to any client application using a Kafka Client library to talk to a *Kafka Cluster*.
-. _Kafka Cluster_ or _Cluster_ refers to a cluster comprising one or more Kafka Brokers.
-. _Downstream_ refers to the area between Kafka Client and Kroxylicious.
-. _Upstream_ refers to the area between Kroxylicious and a Kafka Cluster.
-
-.Kroxylicious landscape
-[a2s, format="svg"]
-....
-.---------------------------------------------------------------------------.
-| : |
-| : +===============+ |
-| : :[Cluster] : |
-| .-----------------. : .----------. : |
-| .----------. |[Kroxylicious] | : |[Broker1] | : |
-| |[Client] | | +------->| | : |
-| | +------->| | : | | : |
-| | | | | : .----------. : |
-| | | | | : : |
-| .----------. | | : .----------. : |
-| | | : |[Broker2] | : |
-| | +------->| | : |
-| | | : | | : |
-| | | : .----------. : |
-| .----------. | | : : |
-| |[Client] | | | : .----------. : |
-| | | | | : |[Broker3] | : |
-| | +------->| +------->| | : |
-| | | | | : | | : |
-| .----------. | | : .----------. : |
-| .-----------------. .===============+ |
-| : |
-| : |
-| [downstream] : [upstream] |
-.---------------------------------------------------------------------------.
-[0,0]: {"fill":"#99d","a2s:delref":1}
-....
-
-Now let's define some concepts used within Kroxylicious itself.
-
-=== Virtual cluster
-
-The _Virtual Cluster_ is the downstream representation of a Kafka Cluster. At the conceptual level, a Kafka Client
-connects to a Virtual Cluster. Kroxylicious proxies all communications made to the Virtual Cluster through to a
-(physical) Kafka Cluster, passing it through the _Filter Chain_.
-
-=== Virtual cluster gateway
-
-Each virtual cluster has one or more dedicated gateways, which Kafka clients use to establish connections.
-
-Each gateway exposes a bootstrap endpoint, which the Kafka Client must specify in its configuration as the https://kafka.apache.org/documentation/#producerconfigs_bootstrap.servers[`bootstrap.servers`] property.
-
-In addition to the bootstrap endpoint, the gateway automatically exposes broker endpoints. There is one broker endpoint
-for each broker of the physical cluster. When the Client connects to a broker endpoint, Kroxylicious proxies all
-communications to the corresponding broker of the (physical) Kafka Cluster.
-
-Kroxylicious automatically intercepts all the Kafka RPC responses that contain a broker address. It rewrites the address
-so that it refers to the corresponding broker endpoint of the Virtual Cluster. This means when the Kafka Client
-goes to connect to, say broker 0, it does so through the Virtual Cluster.
-
-Defining multiple gateways for a virtual cluster is useful when exposing it across different network segments.
-For example, in Kubernetes, you might configure one gateway for on-cluster traffic and another for off-cluster traffic.
-
-=== Target cluster
-
-The _Target Cluster_ is the definition of physical Kafka Cluster within the Kroxylicious itself.
-
-A _Virtual Cluster_ has exactly one _Target Cluster_.
-
-There can be a _one-to-one_ relationship between Virtual Clusters and Target Clusters.
-The other possibility is _many-to-one_, where many Virtual Clusters point to the same Target Cluster. The
-many-to-one pattern is exploited by filters such as the xref:multi-tenancy/proc-multi-tenancy.adoc#proc-multi-tenancy-{context}[Multi-tenancy]
-filter.
-
-.One-to-One relationship between Virtual Cluster and Target Cluster
-[a2s, format="svg"]
-....
-.-------------------------------------------------------------------------------------.
-| |
-| '-------------------------------------' '====================' |
-| '---------' |[Kroxylicious] | :[Cluster] : |
-| |[Client] |=+ | | : : |
-| '---------' : | '----------------------------' | : '---------' : |
-| : | |[Virtual Cluster] |===+====|=====>|[Broker] | : |
-| : | | | | : | | : |
-| +===|===>| '---------' | | : '---------' : |
-| : | | |[Gateway]| | | : : |
-| +===|===>| '---------' | | : '---------' : |
-| | | |===+====:==+==>|[Broker] | : |
-| | '----------------------------' | : | | : |
-| | | : '---------' : |
-| '-------------------------------------' '====================' |
-.-------------------------------------------------------------------------------------.
-[0,0]: {"fill":"#99d","a2s:delref":1}
-....
-
-.Many-to-one between Virtual Cluster and Target Cluster
-[a2s, format="svg"]
-....
-.-------------------------------------------------------------------------------------.
-| |
-| '-------------------------------------' '====================' |
-| '---------' |[Kroxylicious] | :[Cluster] : |
-| |[Client] |=+ | | : : |
-| '---------' : | '----------------------------' | : '---------' : |
-| : | |[Virtual Cluster A] |===+=+==|==+==>|[Broker] | : |
-| +===|===>| '---------' | | : : | | : |
-| : | | |[Gateway]| | | : : '---------' : |
-| +===|===>| '---------' | | : : : |
-| | | | | : : '---------' : |
-| | | |===+====:==+==>|[Broker] | : |
-| | '----------------------------' | : : : | | : |
-| '---------' | | : : : '---------' : |
-| |[Client] |=+ | '----------------------------' | : : : : |
-| '---------' : | |[Virtual Cluster B] |===+=+ '====================' |
-| +===|===>| '---------' | | : |
-| : | | |[Gateway]| | | : |
-| +===|===>| '---------' | | : |
-| | | | | : |
-| | | |===+=======+ |
-| | '----------------------------' | |
-| '-------------------------------------' |
-.-------------------------------------------------------------------------------------.
-[0,0]: {"fill":"#99d","a2s:delref":1}
-....
-
-A one-to-many pattern, where one Virtual Cluster points to many Target Clusters (providing amalgamation),
-is not a supported use-case.
-
-=== Filter chain
-
-A _Filter Chain_ consists of an *ordered list* of pluggable _protocol filters_.
-
-A _protocol filter_ implements some logic for intercepting, inspecting and/or manipulating Kafka protocol messages.
-Kafka protocol requests (such as `Produce` requests) pass sequentially through each of the protocol filters in the
-chain, beginning with the 1st filter in the chain and then following with the subsequent filters, before being
-forwarded to the broker.
-
-When the broker returns a response (such as a `Produce` response) the protocol filters in the chain are invoked in the
-reverse order (that is, beginning with the nth filter in the chain, then the n-1th and so on) with each having the
-opportunity to inspect and/or manipulating the response. Eventually a response is returned to the client.
-
-The description above describes only the basic capabilities of the protocol filter. Richer features of filters
-are described later.
-
-// TODO document additional filter behaviours https://github.com/kroxylicious/kroxylicious/issues/420
-
-.Illustration of a request and response being manipulated by filters in a chain
-[a2s, format="svg"]
-....
-.----------------------------------------------------------------------------------------------------------------------.
-| |
-| '---------------------------------------------------------------' |
-| |[Kroxylicious] | |
-| | | |
-| | '----------------------------------------------------' | '--------------------' |
-| | |[Virtual Cluster] | | |[Cluster] | |
-| '-------------' | | '----------' '----------' '----------' | | | '------------' | |
-| |[Client] | | | |[Filter1] | |[Filter2] | |[Filter3] | | | | |[Broker] | | |
-| | |======|===|==>| |====>| |====>| |===|======|======|===>| | | |
-| | | A | | | F(A)-->B | B | F(B)-->C | C | F(C)-->D | | | | D | | | |
-| | | | | | | | | | | | | | | | | |
-| | |<=====|===|===| |<====| |<====| |<==|======|======|====| | | |
-| | | W | | | f(X)-->W | X | f(Y)-->X | Y | f(Z)-->Y | | | | Z | | | |
-| '-------------' | | '----------' '----------' '----------' | | | '------------' | |
-| | | | | '--------------------' |
-| | '----------------------------------------------------' | |
-| | | |
-| '---------------------------------------------------------------' |
-| |
-.----------------------------------------------------------------------------------------------------------------------.
-[0,0]: {"fill":"#99d","a2s:delref":1}
-....
-
-As mentioned above, Kroxylicious takes the responsibility to rewrite the Kafka RPC responses that carry broker address
-information so that they reflect the broker addresses exposed by the Virtual Cluster. These are the
-https://kafka.apache.org/protocol.html#The_Messages_Metadata[`Metadata`],
-https://kafka.apache.org/protocol.html#The_Messages_DescribeCluster[`DescribeCluster`] and
-https://kafka.apache.org/protocol.html#The_Messages_FindCoordinator[`FindCoordinator`] responses. This processing is
-entirely transparent to the work of the protocol filters. _Filter authors_ are free to write their own filters that
-intercept these responses too.
-
-=== Filter composition
-
-An important principal for the protocol filter API is that filters should _compose_ nicely.
-That means that filters generally don't know what other filters might be present in the chain, and what they might be doing to messages.
-When a filter forwards a request or response it doesn't know whether the message is being sent to the next filter in the chain, or straight back to the client.
-
-Such composition is important because it means a _proxy user_ can configure multiple filters (possibly written by several _filter authors_) and expect to get the combined effect of all of them.
-
-It's never quite that simple, of course.
-In practice they will often need to understand what each filter does in some detail in order to be able to operate their proxy properly, for example by understanding whatever metrics each filter is emitting.
-
-== Implementation
-
-The proxy is written in Java, on top of https://netty.io[Netty].
-The usual https://netty.io/4.1/api/io/netty/channel/ChannelHandler.html[`ChannelHandlers`] provided by the Netty project are used where appropriate (e.g. SSL support uses https://netty.io/4.1/api/io/netty/handler/ssl/SslHandler.html[`SslHandler`]), and Kroxylicious provides Kafka-specific handlers of its own.
-
-The Kafka-aware parts use the Apache Kafka project's own classes for serialization and deserialization.
-
-Protocol filters get executed using a handler-per-filter model.
-
-== Deployment topologies
-
-The proxy supports a range of possible deployment topologies.
-Which style is used depends on what the proxy is meant to _achieve_, architecturally speaking.
-Broadly speaking a proxy instance can be deployed:
-
-As a forward proxy::
-Proxying the access of one or more clients to a particular cluster/broker that might also accessible (to other clients) directly.
-+
-// TODO include a diagram
-+
-Topic-level encryption provides one example use case for a forward proxy-style deployment.
-This might be applicable when using clients that don't support interceptors, or if an organization wants to apply the same encryption policy in a single place, securing access to the keys within their network.
-
-As a reverse proxy::
-Proxying access for all clients trying to reach a particular cluster/broker.
-+
-// TODO include a diagram
-+
-Transparent multi-tenancy provides an example use case for a reverse proxy.
-While Apache Kafka itself has some features that enable multi-tenancy, they rely on topic name prefixing as the primary mechanism for ensuring namespace isolation.
-Tenants have to adhere to the naming policy and know they're a tenant of a larger shared cluster.
-+
-_Transparent_ multi-tenancy means each tenant has the illusion of having their own cluster, with almost complete freedom over topic and group naming, while still actually sharing a cluster.
-
-// TODO we probably don't need the level of detail below, just summarize
-// and provide the detail in the deploying section
-
-We can further classify deployment topologies in how many proxy instances are used.
-For example:
-
-* Single proxy instance (sidecar)
-* Proxy pool
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuration-outline.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuration-outline.adoc
deleted file mode 100644
index 6a2c6e01..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuration-outline.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-[id='con-configuration-outline-{context}']
-= Outline of a Kroxylicious configuration
-
-[role="_abstract"]
-The following example shows the overall outline of a simple Kroxylicious configuration.
-While not complete (as indicated by `# ...`), it illustrates the essential structure.
-
-[id='con-basic-structure-{context}']
-.Basic outline of a Kroxylicious configuration
-[source,yaml]
-----
-filterDefinitions: # <1>
- - name: example # <2>
- type: org.example.filter.Example # <3>
- config: # <4>
- # ...
-defaultFilters: <5>
- - example
-virtualClusters: # <6>
- - name: my-cluster-proxy
- targetCluster: # <7>
- # ...
- gateways: # <8>
- - name: ...
- # ...
-# ...
-----
-<1> A list of named filter definitions.
-<2> A filter definition called `example`. The definitions must each have a unique name.
-<3> The name of the filter class implementation for the `example` filter. Required.
-<4> The configuration for the `example` filter instance. Usually required for non-trivial filters.
-<5> A list of default filters. It's possible to override this list at the virtual cluster level.
-<6> List of virtual clusters specified by name, with cluster-specific configurations.
-<7> Configuration of the actual Kafka cluster that is proxied by the 'my-cluster-proxy' virtual cluster.
-<8> Configuration of the gateways for this virtual cluster.
-
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-filters.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-filters.adoc
deleted file mode 100644
index 5f4dac22..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-filters.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-[id='ref-configuring-filters-{context}']
-= Defining filters
-
-Filters in Kroxylicious can be defined globally with `filterDefinitions`, applied by default using `defaultFilters`, or customized for specific virtual clusters.
-The following example shows how these elements work together flexibly:
-
-[id='con-filterDefinitions-defaultFilters-{context}']
-.Example configuration showing global filter definitions applied as defaults and to virtual cluster
-[source,yaml]
-----
-filterDefinitions:
- - name: encryption
- type: RecordEncryption
- config:
- # ...
- - name: validation
- type: RecordValidation
- config:
- # ...
- - name: special-encryption
- type: RecordEncryption
- config:
- # ...
-defaultFilters:
- - validation
- - encryption
-virtualClusters:
- - name: my-proxy-with-default-filters
- # ...
- - name: my-proxy-with-custom-filters
- filters:
- - validation
- - special-encryption
- # ...
-# ...
-----
-
-* The order of definitions in `filterDefinitions` does not matter.
-* Each filter definition in `filterDefinitions` must have a unique `name`, but you can have multiple definitions with the same type and different configurations (as with `encryption` and `special-encryption` in the example).
-* The order of `defaultFilters` determines the sequence in which the filters are applied to incoming client requests. In the example, records are first validated and then encrypted.
-* The `defaultFilters` are used for all virtual clusters which don't define their own `filters`, such as `my-proxy-with-default-filters`.
-* The `defaultFilters` property is optional. It is useful when all virtual clusters must use the same filters. There's no need to specify it if all virtual clusters have specific `filters` defined.
-* When a virtual cluster has defined `filters`, like `my-proxy-with-custom-filters`, then those filters are used instead of the `defaultFilters`.
-* When using `defaultFilters` or a virtual cluster's `filters` to reference a filter definition, you must define a filter with the corresponding name in `filterDefinitions`.
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-cipher.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-cipher.adoc
deleted file mode 100644
index 7b905fb2..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-cipher.adoc
+++ /dev/null
@@ -1,31 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy-broker-connection.adoc
-
-[id='con-configuring-kafkaservice-cipher-{context}']
-= TLS cipher suite configuration for proxy-to-cluster connections
-
-include::../../snippets/snip-tls-cipher-suite.adoc[]
-
-.Example `KafkaService` configured so that the proxy will negotiate TLS connection using only the listed ciphers.
-[source,yaml]
-----
-kind: KafkaService
-metadata:
- # ...
-spec:
- bootstrapServers: kafka.example.com:9092
- tls:
- # ...
- cipherSuites: # <1>
- allow: # <2>
- - TLS_AES_128_GCM_SHA256
- - TLS_AES_256_GCM_SHA384
-----
-<1> The `cipherSuites` object configures the cipher suites.
-<2> `allow` lists the cipher suites which are permitted.
-
-The `cipherSuites` property also supports `deny`, if you prefer to list the cipher suites to exclude instead.
-
-The names of the cipher suites supported depend on the JVM in the proxy container image.
-See {cipherSuiteNames}.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-protocol.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-protocol.adoc
deleted file mode 100644
index 06b23087..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-protocol.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy-broker-connection.adoc
-
-[id='con-configuring-kafkaservice-protocol-{context}']
-= TLS version configuration for proxy-to-cluster connections
-
-include::../../snippets/snip-tls-protocol-versions.adoc[]
-
-This example configures a `KafkaService` to allow only TLS v1.3 when connecting to `kafka.example.com`.
-
-.Example `KafkaService` with restricted TLS protocol versions.
-[source,yaml]
-----
-kind: KafkaService
-metadata:
- # ...
-spec:
- bootstrapServers: kafka.example.com:9092
- tls:
- # ...
- protocols: # <1>
- allow: # <2>
- - TLSv1.3
-----
-<1> The `protocols` property configures the TLS protocol versions
-<2> `allow` lists the versions of TLS which are permitted.
-
-The `protocols` property also supports `deny`, if you prefer to list the versions to exclude instead.
-
-The names of the TLS protocol versions supported depend on the JVM in the proxy container image.
-See {tlsProtocolNames}.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-trust.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-trust.adoc
deleted file mode 100644
index 6724fa45..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-kafkaservice-trust.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy-broker-connection.adoc
-
-[id='con-configuring-kafkaservice-trust-{context}']
-= TLS trust configuration for proxy-to-cluster connections
-
-By default, the proxy uses the platform's default trust store when connecting to the proxied cluster over TLS.
-This works if the cluster's TLS certificates are signed by a well-known public Certificate Authority (CA), but fails if they’re signed by a private CA instead.
-
-IMPORTANT: It is good practice to configure trust explicitly, even when proxied cluster's TLS certificates are signed by a public CA.
-
-This example configures a `KafkaService` to trust TLS certificates signed by any Certificate Authority (CA) listed in the `trusted-cas.pem` entry of the `ConfigMap` named `trusted-cas`.
-
-.Example `KafkaService` configuration for trusting certificates.
-[source,yaml]
-----
-kind: KafkaService
-metadata:
- # ...
-spec:
- bootstrapServers: kafka.example.com:9092
- tls:
- trustAnchorRef: # <1>
- kind: ConfigMap # <2>
- name: trusted-cas # <3>
- key: trusted-cas.pem # <4>
- # ...
-----
-<1> The `trustAnchorRef` property references a separate Kubernetes resource which contains the CA certificates to be trusted
-<2> The `kind` is optional and defaults to `ConfigMap`.
-<3> The `name` of the resource of the given `kind`. This resource must exist in the same namespace as the `KafkaService`
-<4> The `key` identifies the entry in the given resource. The corresponding value must be a PEM-encoded set of CA certificates.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-tls-between-client-and-proxy.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-tls-between-client-and-proxy.adoc
deleted file mode 100644
index 52fc04d4..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-tls-between-client-and-proxy.adoc
+++ /dev/null
@@ -1,60 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-client-proxy-connection.adoc
-
-[id='con-configuring-virtualkafkacluster-{context}']
-= TLS configuration for client-to-proxy connections
-
-This example shows a `VirtualKafkaCluster`, exposing it to Kafka clients running on the same Kubernetes cluster.
-It uses TLS as the transport protocol so that communication between Kafka clients and the proxy is encrypted.
-
-.Example `VirtualKafkaCluster` configuration
-[source,yaml]
-----
-kind: VirtualKafkaCluster
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- name: my-cluster
- namespace: my-proxy
-spec:
- proxyRef: # <1>
- name: simple
- targetKafkaServiceRef: # <2>
- name: my-cluster
- ingresses:
- - ingressRef: # <3>
- name: cluster-ip
- tls: # <4>
- certificateRef:
- name: server-certificate
- kind: Secret
-----
-<1> The `proxyRef` names the `KafkaProxy` resource that this virtual cluster is part of.
- It must be in the same namespace as the `VirtualKafkaCluster`.
-<2> The virtual cluster names the `KafkaService` to be proxied.
- It must be in the same namespace as the `VirtualKafkaCluster`.
-<3> The virtual cluster can be exposed by one or more ingresses.
- Each ingress must reference a `KafkaProxyIngress` in the same namespace as the `VirtualKafkaCluster`.
-<4> If the ingress supports TLS, the `tls` property configures the TLS server certificate to use.
-
-Within a `VirtualKafkaCluster`, an ingress's `tls` property configures TLS for that ingress.
-The `tls.certificateRef` specifies the `Secret` resource holding the TLS server certificate that the proxy uses for clients connecting through this ingress.
-The referenced `KafkaProxyIngress` also needs to be configured for TLS.
-
-.Example `KafkaProxyIngress` configuration for TLS
-[source,yaml]
-----
-kind: KafkaProxyIngress
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- name: cluster-ip
- namespace: my-proxy
-spec:
- proxyRef: # <1>
- name: simple
- clusterIP: # <2>
- protocol: TLS # <3>
-----
-<1> The ingress must reference a `KafkaProxy` in the same namespace as the `KafkaProxyIngress`.
-<2> Exposes the proxy to Kafka clients inside the same Kubernetes cluster using a `ClusterIP` service.
-<3> The ingress uses `TLS` as the transport protocol.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-toplevel-other-settings.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-toplevel-other-settings.adoc
deleted file mode 100644
index 5994d557..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-toplevel-other-settings.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-[id='ref-configuring-toplevel-other-settings-{context}']
-= Configuring other top level settings
-
-== Management HTTP endpoints
-
-The proxy can run an HTTP server for exposing basic management information.
-This is configured with the top level `management` property.
-
-[id='con-configuring-admin-http-{context}']
-.Configuration fragment showing the `management` property
-[source,yaml]
-----
-# ... (filterDefinitions, virtualClusters etc)
-management:
- bindAddress: 0.0.0.0 <1>
- port: 9190 <2>
- endpoints: # <3>
- prometheus: {} # <4>
-----
-<1> The address the HTTP server should bind to. Defaults to `0.0.0.0`.
-<2> The port the HTTP server should bind to. Defaults to `9190`.
-<3> Control over the exposed endpoints
-<4> If present and not null, exposes a Prometheus scrape endpoint at path `/metrics`.
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-client-tls.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-client-tls.adoc
deleted file mode 100644
index c94b0f00..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-client-tls.adoc
+++ /dev/null
@@ -1,201 +0,0 @@
-[id='con-configuring-client-connections-{context}']
-= Securing connections from clients
-
-[role="_abstract"]
-To secure client connections to virtual clusters, configure TLS within the virtual cluster gateway by doing the following:
-
-* Obtain a server certificate for the virtual cluster from a Certificate Authority (CA). +
-Ensure the certificate matches the names of the virtual cluster gateway's bootstrap and broker addresses. +
-This may require wildcard certificates and Subject Alternative Names (SANs).
-
-* Provide the TLS configuration using the `tls` properties in the virtual cluster gateway's configuration to enable it to present the certificate to clients.
-Depending on your certificate format, apply one of the following examples.
-
-* For mutual TLS, use the `trust` properties to configure the virtual cluster gateway to use TLS client authentication.
-
-* If required, you can restrict the TLS protocols and cipher suites that are used to form the TLS connection.
-
-Examples below illustrate how these steps may be done.
-
-NOTE: TLS is recommended for production configurations.
-
-.Example applying a PKCS #12 server certificate to a virtual cluster gateway
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- key:
- storeFile: /server.p12 # <1>
- storePassword:
- passwordFile: /store.password # <2>
- keyPassword:
- passwordFile: /key.password # <3>
- storeType: PKCS12 # <4>
-# ...
-----
-<1> PKCS #12 store containing the private-key and certificate/intermediates of the virtual cluster gateway.
-<2> Password to protect the PKCS #12 store.
-<3> (Optional) Password for the key. If a password is not specified, the keystore’s password is used to decrypt the key too.
-<4> (Optional) Keystore type. If a keystore type is not specified, the default JKS (Java Keystore) type is used.
-
-.Example applying a PEM server certificate and key pair to a virtual cluster gateway
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- key:
- privateKeyFile: /server.key # <1>
- certificateFile: /server.crt # <2>
- keyPassword:
- passwordFile: /key.password # <3>
-# ...
-----
-<1> Private key of the virtual cluster gateway.
-<2> Public certificate of the virtual cluster gateway.
-<3> (Optional) Password for the key.
-
-You can configure the virtual cluster gateway to require that clients present a certificate for authentication.
-The virtual cluster gateway verifies that the client's certificate is signed by one of the CA certificates contained in a trust store.
-If verification fails, the client's connection is refused.
-
-.Example applying TLS client authentication using a PKCS #12 truststore
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- key:
- # ...
- trust:
- storeFile: /trust.p12 # <1>
- storePassword:
- passwordFile: /trust.password # <2>
- storeType: PKCS12 # <3>
- trustOptions:
- clientAuth: REQUIRED # <4>
-# ...
-----
-<1> PKCS #12 store containing CA certificate(s) used to verify that the client's certificate is trusted.
-<2> (Optional) Password to protect the PKCS #12 store.
-<3> (Optional) Keystore type. If a keystore type is not specified, the default JKS (Java Keystore) type is used.
-<4> (Optional) Client authentication mode.
-If set to `REQUIRED`, the client must present a valid certificate.
-If set to `REQUESTED`, the client is requested to present a certificate. If presented, the certificate is validated. If the client chooses not to present a certificate the connection is still allowed.
-If set to `NONE`, client authentication is disabled.
-If a client authentication mode is not specified, then the default behaviour is `REQUIRED`.
-
-NOTE: The client's identity, as established through TLS client authentication, is currently not relayed to the target cluster.
-For more information, see the {github-issues}/1637[related issue^].
-
-You can restrict the TLS protocols by specifying either an allow list of TLS protocols to be enabled, or a deny list of
-TLS protocols to be disallowed from the platform's default.
-If both an allow and a deny list are specified, the resulting list of TLS protocols includes only those protocols from the
-allow list that are not in the deny list.
-If neither list is specified, the virtual cluster uses the default TLS protocols provided by the platform.
-
-When the client connects, it negotiates the highest mutually acceptable TLS protocol with the virtual cluster.
-If the two have no protocols in common, the connection fails.
-
-The names of the TLS protocols are defined by {java-17-specs}/security/standard-names.html#sslcontext-algorithms[Java specification].
-
-.Example restricting TLS protocols using an allow list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- # ...
- protocols:
- allowed: # <1>
- - TLSv1.3
- - TLSv1.2
-----
-<1> List of allowed TLS protocols.
-
-.Example restricting TLS protocols using a deny list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- # ...
- protocols:
- denied: # <1>
- - TLSv1.1
-----
-<1> List of disallowed TLS protocols.
-
-You can restrict the TLS cipher suite by specifying either an allow list of cipher suites to be enabled, in preference
-order, or a deny list of ciphers suites to be disallowed from the platform's default.
-If both an allow and a deny list are specified, the resulting list of cipher suites includes only those ciphers from the
-allow list that are not in the deny list.
-If neither list is specified, the virtual cluster uses the default cipher suites (and preference order) provided by the platform.
-
-When the client connects, it negotiates the most preferred mutually acceptable cipher suite with the virtual cluster.
-If the two have no cipher suites in common, the connection fails.
-
-The names of the cipher suite are defined by {java-17-specs}/security/standard-names.html#jsse-cipher-suite-names[Java specification].
-
-.Example restricting cipher suites using an allow list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- # ...
- cipherSuites:
- allowed: # <1>
- - TLS_ECDHE_ECDSA_WITH_AES_256_CCM
- - TLS_ECDHE_ECDSA_WITH_AES_128_CCM
-----
-<1> List of allowed cipher suites in preference order.
-
-.Example restricting cipher suites using a deny list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- # ...
- tls:
- # ...
- cipherSuites:
- denied: # <1>
- - TLS_KRB5_WITH_3DES_EDE_CBC_MD5
-----
-<1> List of disallowed cipher suites.
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-gateways.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-gateways.adoc
deleted file mode 100644
index 63ff46fd..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-gateways.adoc
+++ /dev/null
@@ -1,274 +0,0 @@
-[id='con-configuring-vc-gateways-{context}']
-= Configuring virtual cluster gateways
-
-[role="_abstract"]
-
-Clients connect to a virtual cluster gateway.
-Each gateway provides a bootstrap address for the initial connection.
-The gateway also facilitates communication between clients and proxied brokers.
-This can be implemented in two ways:
-
-Port Identifies Node:: The gateway binds separate ports—one for each broker as well as an additional one for the bootstrap address.
-Clients make connections to the different port numbers to interact with each broker.
-SNI Host Identifies Node:: The gateway assigns a unique hostname to each broker.
-Clients make connections to these distinct hostnames to interact with the respective brokers.
-The gateway uses SNI (Server Name Indication) to identify the target broker for the client's connection.
-
-IMPORTANT: You must make sure that the gateway's bootstrap address and generated broker addresses are resolvable and routable by the Kafka Client. You must also make sure firewall rules permit traffic to required port numbers.
-
-== Port Identifies Node
-
-In the Port Identifies Node scheme, the virtual cluster opens a separate port for each proxied broker in addition to
-a separate port for the bootstrap.
-
-By default, this scheme assumes that the target cluster comprises three nodes with broker ids 0..2.
-If this is inadequate, additional configuration can be provided describing the broker topology of the target broker.
-
-This scheme can be used with both plain and TLS downstream connections.
-
-This scheme works best with straightforward configurations where the target cluster uses a known minimum broker ID and uses stable sets of broker IDs.
-For more complex cases, it is recommended to use the SNI Host Identifies Node scheme.
-
-IMPORTANT: When using this scheme, you have the responsibility to avoid port number collision. Ensure that each gateway has its own range of port numbers and these do not overlap with the range used by another gateway, or the gateway of another virtual cluster.
-
-[id='con-configuring-vc-gateways-port-identifies-node-{context}']
-.Example Port Identifies Node configuration
-
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- portIdentifiesNode:
- bootstrapAddress: localhost:9192 # <1>
- # ...
-# ...
-----
-<1> The bootstrap address used by Kafka clients.
-
-With the example configuration above, the gateway exposes a target cluster of up to three brokers with node ids `0`, `1`, `2`.
-The advertised address is defaulted to that of the bootstrap host name.
-Port numbers are assigned sequentially beginning at bootstrap port number + 1.
-
-The gateway exposes the following three broker addresses:
-
-|===
-|Node Id|Broker Address
-
-|0
-|localhost:9193
-
-|1
-|localhost:9194
-
-|2
-|localhost:9195
-|===
-
-.Example Port Identifies Node configuration with customized broker address
-
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- portIdentifiesNode:
- bootstrapAddress: localhost:9192 # <1>
- advertisedBrokerAddressPattern: mycluster.example.com # <2>
- brokerStartPort: 9200 # <3>
- # ...
-# ...
-----
-<1> The bootstrap address used by Kafka clients.
-<2> (Optional) The advertised broker address pattern used to form broker addresses. If not defined, it defaults to the hostname part of the bootstrap address.
-<3> (Optional) The starting number for the broker port range. Defaults to the port of the bootstrap address plus 1.
-
-With the example configuration above, the gateway exposes a target cluster of up to three brokers with node ids `0`, `1`, `2`.
-The advertised broker address is defined as `mycluster.example.com`.
-Port numbers are assigned sequentially beginning at `9200`.
-
-The gateway exposes the following three broker addresses:
-
-|===
-|Node Id|Broker Address
-
-|0
-|mycluster.example.com:9200
-
-|1
-|mycluster.example.com:9201
-
-|2
-|mycluster.example.com:9203
-|===
-
-.Example Port Identifies Node configuration with customized node ranges
-
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- portIdentifiesNode:
- bootstrapAddress: localhost:9192 # <1>
- advertisedBrokerAddressPattern: mycluster.example.com # <2>
- nodeIdRanges: # <3>
- - name: mixed
- start: 1
- end: 3
- - name: brokers
- start: 100
- end: 103
-
- # ...
-# ...
-----
-<1> The bootstrap address used by Kafka clients.
-<2> (Optional) The advertised broker address pattern used to form broker addresses. If not defined, it defaults to the hostname part of the bootstrap address.
-<3> (Optional) One or more node id ranges. If omitted, it defaults to a single range of node IDs 0..2 (inclusive).
-
-With the example configuration above, the gateway exposes a target cluster of up to six nodes with node ids `1..3` and `101..103`.
-The advertised broker address is defined as `mycluster.example.com`.
-Port numbers are assigned sequentially beginning at `9193` (bootstrap port number + 1).
-
-The gateway exposes the following six broker addresses:
-
-|===
-|Node Id|Broker Address
-
-|1
-|mycluster.example.com:9193
-
-|2
-|mycluster.example.com:9194
-
-|3
-|mycluster.example.com:9195
-
-|101
-|mycluster.example.com:9196
-
-|102
-|mycluster.example.com:9197
-
-|103
-|mycluster.example.com:9198
-
-|===
-
-The `advertisedBrokerAddressPattern` configuration parameter accepts the `$(nodeId)` replacement token, which is optional.
-If included, `$(nodeId)` is replaced by the broker's https://kafka.apache.org/documentation/#brokerconfigs_node.id[`node.id`] (or https://kafka.apache.org/documentation/#brokerconfigs_broker.id[`broker.id`]) in the target cluster.
-
-[id='con-configuring-vc-gateways-snihost-identifies-node-{context}']
-
-== SNI Host Identifies Node
-
-In the SNI Host Identifies Node scheme, unique broker hostnames are used to know where to route the traffic.
-As this scheme relies on SNI (Server Name Indication), which is a TLS extension, TLS connections are required. It cannot be used with plain text connections.
-
-In this scheme, you can either share the port across multiple virtual cluster gateways or assign a separate port
-for each virtual cluster gateway.
-However, you cannot use a port that is already assigned to a virtual cluster gateway using the Port Identifies Node scheme.
-
-IMPORTANT: When using this scheme, you have the responsibility to make sure that DNS for bootstrap and brokers resolve
-to an IP address that is routed to the proxy. Wildcard DNS is one way to achieve this.
-
-.Example SNI Host Identifies Node configuration
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- sniHostIdentifiesNode:
- bootstrapAddress: mycluster.example.com:9192 # <1>
- advertisedBrokerAddressPattern: mybroker-$(nodeId).mycluster.example.com <2>
- tls:
- key: ... <3>
- # ...
-# ...
-----
-<1> The bootstrap address used by Kafka clients.
-<2> The advertised broker address pattern used to form broker addresses. It must include the placeholder $(nodeId) which
- is substituted for the node ID.
-<3> TLS configuration.
-
-With the example configuration above, the gateway accepts all traffic on port 9192.
-Any TLS connections received with the SNI of `mycluster.example.com` are routed as bootstrap.
-Any connections received with SNI matching `mybroker-$(nodeId).mycluster.example.com` are routed to the upstream broker with the same node ID.
-The configuration exposes a target cluster with any number of brokers. It does not need prior knowledge of the node IDs used by the brokers.
-
-The gateway exposes the following broker addresses:
-
-|===
-|Node Id|Broker Address
-
-|0
-|mybroker-0.mycluster.example.com:9192
-
-|...
-|...
-
-|_n_
-|mybroker-_n_.mycluster.example.com:9192
-
-|===
-
-Both the `advertisedBrokerAddressPattern` and `bootstrapAddress` configuration parameters accept the `$(virtualClusterName)` replacement token,
-which is optional. If included, `$(virtualClusterName)` is replaced with the name of the gateway's virtual cluster.
-
-.Example SNI Host Identifies Node configuration with customized advertised port
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- gateways:
- - name: mygateway
- sniHostIdentifiesNode:
- bootstrapAddress: mycluster.example.com:9192 # <1>
- advertisedBrokerAddressPattern: mybroker-$(nodeId).mycluster.example.com:443 <2>
- tls:
- key: ... <3>
- # ...
-# ...
-----
-<1> The bootstrap address used by Kafka clients.
-<2> The advertised broker address pattern and port number used to form broker addresses. It must include the placeholder $(node)
- which will be substituted for the node id.
-<3> TLS configuration.
-
-With the example configuration above, Kroxylicious is instructed to listen on port 9192, but advertise brokers of this virtual cluster as
-being available on port 443. This feature is useful where a network intermediary (such as another proxy or
-load balancer) is port forwarding.
-
-The gateway exposes the following broker addresses:
-
-|===
-|Node Id|Broker Address
-
-|0
-|mybroker-0.mycluster.example.com:443
-
-|...
-|...
-
-|_n_
-|mybroker-_n_.mycluster.example.com:443
-
-|===
-
-NOTE: Single port operation may have cost advantages when using load balancers of public clouds, as it allows
-a single cloud provider load balancer to be shared across all virtual clusters.
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-other-settings.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-other-settings.adoc
deleted file mode 100644
index 035261ba..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-other-settings.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-[id='ref-configuring-vc-other-settings-{context}']
-= Configuring other Virtual Cluster settings
-
-== Per-virtual cluster logging
-
-You can enable low level logging on a per-virtual cluster basis.
-The `logNetwork` property controls logging of information about requests and responses at the network level, before they've been decoded into Kafka requests and responses.
-The `logFrames` property controls logging of the decoded requests and responses.
-
-
-[id='con-configuring-vc-logging-{context}']
-.Configuration fragment showing logging properties
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- logNetwork: true <1>
- logFrames: true <2>
- # ...
-----
-<1> Enables low-level network logging for the virtual cluster.
-<2> Enables low-level protocol frame logging for the virtual cluster.
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-target-tls.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-target-tls.adoc
deleted file mode 100644
index 2904e4bf..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-vc-target-tls.adoc
+++ /dev/null
@@ -1,165 +0,0 @@
-[id='con-configuring-target-cluster-connections-{context}']
-= Securing connections to target clusters
-
-[role="_abstract"]
-To secure connections from the virtual cluster to the upstream cluster, configure the target cluster's TLS setting by
-doing the following:
-
-* If the upstream is using a private CA, use the `trust` properties to configure a truststore for the target cluster.
-
-* If you want to use mutual TLS, specify the certificate with the `key` property to identify the virtual cluster to the upstream.
-
-* If required, you can restrict the TLS protocols and cipher suites that are used to form the TLS connection.
-
-NOTE: TLS is recommended on Kafka clients and virtual clusters for production configurations.
-
-Examples below illustrate how these steps may be done.
-
-Using an empty object (`{}`) enables TLS using the platform's defaults. This means that platform trust, and
-default protocols and cipher suites will be used. This option is suitable if the upstream cluster is using a TLS
-certificate signed by a public CA and the platform's defaults are suitable.
-
-.Example enabling TLS for a target cluster using platform defaults
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls: {}
-# ...
-----
-
-If it is using a TLS certificate signed by a private CA, you must add truststore configuration for the target cluster.
-The example illustrates using PKCS #12 format. PEM format is supported too.
-
-.Example specifying a truststore
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- trust:
- storeFile: /trust.p12 # <1>
- storePassword:
- passwordFile: /store.password # <2>
- storeType: PKCS12 # <3>
-# ...
-----
-<1> PKCS #12 store for the public CA certificate of the Kafka cluster.
-<2> Password to access the public Kafka cluster CA certificate.
-<3> (Optional) Keystore type. If a keystore type is not specified, the default JKS (Java Keystore) type is used.
-
-For mutual TLS, add a keystore configuration for the virtual cluster.
-The following example uses a PEM format server certificate and key pair.
-PKCS #12 keystore format is supported too.
-
-.Example configuring mutual TLS
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- key:
- privateKeyFile: /client.key # <1>
- certificateFile: /client.crt # <2>
-# ...
-----
-<1> Private key of the virtual cluster.
-<2> Public CA certificate of the virtual cluster.
-
-The TLS protocols and cipher suites available to the TLS connection may also be configured.
-
-.Example restricting TLS protocols using an allow list
-[source,yaml]
-----
-# ...
-virtualClusters:
- - name: my-cluster-proxy
- # ...
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- # ...
- protocols:
- allowed: # <1>
- - TLSv1.3
- - TLSv1.2
-----
-<1> List of allowed TLS protocols.
-
-.Example restricting TLS protocols using a deny list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- # ...
- protocols:
- denied: # <1>
- - TLSv1.1
-----
-<1> List of disallowed TLS protocols.
-
-.Example restricting cipher suites using an allow list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- # ...
- cipherSuites:
- allowed: # <1>
- - TLS_ECDHE_ECDSA_WITH_AES_256_CCM
- - TLS_ECDHE_ECDSA_WITH_AES_128_CCM
-----
-<1> List of allowed cipher suites.
-
-.Example restricting cipher suites using a deny list
-
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- # ...
- cipherSuites:
- denied: # <1>
- - TLS_KRB5_WITH_3DES_EDE_CBC_MD5
-----
-<1> List of disallowed cipher suites.
-
-For the purposes of testing (that is, outside a production environment), you can set the `insecure` property to `true`
-to disable TLS trust checks (hostname verification and certificate validation) so that the Kroxylicious can connect to
-any Kafka cluster.
-
-.Example configuration to disable TLS trust checks
-[source,yaml]
-----
-virtualClusters:
- - name: my-cluster-proxy
- targetCluster:
- bootstrapServers: dev-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093
- tls:
- trust:
- insecure: true
-# ...
-----
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-configuring-virtual-clusters.adoc b/docs/v0.13.0/_files/modules/configuring/con-configuring-virtual-clusters.adoc
deleted file mode 100644
index c62a2967..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-configuring-virtual-clusters.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-[id='con-configuring-virtual-clusters-{context}']
-= Configuring virtual clusters
-
-[role="_abstract"]
-A Kafka cluster is represented by the proxy as a virtual cluster.
-Clients communicate with the virtual cluster rather than the actual cluster.
-When Kroxylicious is deployed, it includes configuration to create virtual clusters.
-
-A virtual cluster has exactly one target cluster, but many virtual clusters can target the same cluster.
-Each virtual cluster targets a single listener on the target cluster, so multiple listeners on the Kafka side are represented as multiple virtual clusters by the proxy.
-Clients connect to a virtual cluster using a `bootstrapServers` address.
-The virtual cluster has a bootstrap address that maps to each broker in the target cluster.
-When a client connects to the proxy, communication is proxied to the target broker by rewriting the address.
-Responses back to clients are rewritten to reflect the appropriate network addresses of the virtual clusters.
-
-You can secure virtual cluster connections from clients and to target clusters.
-
-Kroxylicious accepts keys and certificates in PEM (Privacy Enhanced Mail), PKCS #12 (Public-Key Cryptography Standards), or JKS (Java KeyStore) keystore format.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-kafkaprotocolfilter-secrets.adoc b/docs/v0.13.0/_files/modules/configuring/con-kafkaprotocolfilter-secrets.adoc
deleted file mode 100644
index 953f6d0c..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-kafkaprotocolfilter-secrets.adoc
+++ /dev/null
@@ -1,52 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-filter.adoc
-
-= Security-sensitive values in filter resources
-
-== Template use and value interpolation
-
-Interpolation is supported in `spec.configTemplate` for the automatic substitution of placeholder values at runtime.
-This allows security-sensitive values, such as passwords or keys, to be specified in Kubernetes `Secret` resources rather than directly in the `KafkaProtocolFilter` resource.
-Likewise, things like trusted CA certificates can be defined in `ConfigMap` resources.
-
-The operator determines which `Secret` and `ConfigMap` resources are referenced by a `KafkaProtocolFilter` resource and declares them as `volumes` in the proxy `Pod`, mounted into the proxy container.
-This example shows how to configure the `RecordEncryptionFilter` using a Vault KMS deployed in the same Kubernetes cluster.
-
-.Example `KafkaProtocolFilter` configuration
-[source,yaml]
-----
-kind: KafkaProtocolFilter
-metadata:
- # ...
-spec:
- type: RecordEncryption # <1>
- configTemplate: # <2>
- kms: VaultKmsService
- kmsConfig:
- vaultTransitEngineUrl: http://vault.vault.svc.cluster.local:8200/v1/transit
- vaultToken:
- password: ${secret:vault:token} # <3>
- selector: TemplateKekSelector
- selectorConfig:
- template: "$(topicName)" # <4>
-----
-<1> The `type` is the Java class name of the proxy filter. If the unqualified name is ambiguous, it must be qualified by the filter package name.
-<2> The `KafkaProtocolFilter` requires a `configTemplate`, which supports _interpolation references_.
-<3> The `password` uses an _interpolation reference_, enclosed by `${` and `}` instead of a literal value. The operator supplies the value at runtime from the specified `Secret`.
-<4> The selector `template` is interpreted by the proxy. It uses different delimiters, `$(` and `)`, than the _interpolation reference_.
-
-== Structure of interpolation references
-
-Let's look at the example interpolation reference `${secret:vault:token}` in more detail.
-
-It starts with `${` and ends with `}`. Between these, it is broken into three parts, separated by colons (`:`):
-
-* `secret` is a _provider_. Supported providers are `secret` and `configmap` (note the use of lower case).
-* `vault` is a _path_. The interpretation of the path depends on the provider.
-* `token` is a _key_. The interpretation of the key also depends on the provider.
-
-For both `secret` and `configmap` providers:
-
-* The path is interpreted as the name of a `Secret` or `ConfigMap` resource in the same namespace as the `KafkaProtocolFilter` resource.
-* The key is interpreted as a key in the `data` property of the `Secret` or `ConfigMap` resource.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-kafkaproxy-cpu-memory-allocation.adoc b/docs/v0.13.0/_files/modules/configuring/con-kafkaproxy-cpu-memory-allocation.adoc
deleted file mode 100644
index 73411c7b..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-kafkaproxy-cpu-memory-allocation.adoc
+++ /dev/null
@@ -1,35 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-operate-resource-allocation.adoc
-
-[id='con-kafkaproxy-cpu-memory-allocation-{context}']
-= Configuring Proxy container CPU and memory resource limits and requests
-
-When you define a `KafkaProxy` resource, a number of Kubernetes `Pods` are created, each with a proxy container.
-Each of these containers runs a single Kroxylicious Proxy process.
-
-By default, these proxy containers are defined without resource limits.
-
-You can learn more about Kubernetes resource management https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/[here].
-
-To manage CPU and memory consumption in your environment, modify the `proxyContainer` section within your `KafkaProxy` specification.
-
-.Example `KafkaProxy` configuration with proxy container resource specification
-[source,yaml]
-----
-kind: KafkaProxy
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- namespace: my-proxy
- name: simple
-spec:
- infrastructure:
- proxyContainer:
- resources:
- requests:
- cpu: '400m'
- memory: '656Mi'
- limits:
- cpu: '500m'
- memory: '756Mi'
-----
diff --git a/docs/v0.13.0/_files/modules/configuring/con-kafkaproxy.adoc b/docs/v0.13.0/_files/modules/configuring/con-kafkaproxy.adoc
deleted file mode 100644
index 86f0685c..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-kafkaproxy.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-deploy-a-proxy.adoc
-
-[id='con-kafkaproxy-{context}']
-= Proxy configuration to host virtual clusters
-
-A `KafkaProxy` resource represents an instance of the Kroxylicious Proxy.
-Conceptually, it is the top-level resource that links together `KafkaProxyIngress`, `VirtualKafkaCluster`, `KafkaService`, and `KafkaProtocolFilter` resources to form a complete working proxy.
-
-`KafkaProxy` resources are referenced by `KafkaProxyIngress` and `VirtualKafkaCluster` resources to define how the proxy is exposed and what it proxies.
-
-.Example `KafkaProxy` configuration
-[source,yaml]
-----
-kind: KafkaProxy
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- namespace: my-proxy
- name: simple
-spec: {} # <1>
-----
-<1> An empty `spec` creates a proxy with default configuration.
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-kafkaproxyingress-for-on-cluster-access.adoc b/docs/v0.13.0/_files/modules/configuring/con-kafkaproxyingress-for-on-cluster-access.adoc
deleted file mode 100644
index f2147e82..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-kafkaproxyingress-for-on-cluster-access.adoc
+++ /dev/null
@@ -1,31 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-deploy-a-proxy.adoc
-
-[id='con-configuring-kafkaproxyingress-on-cluster-access-{context}']
-= Networking configuration for on-cluster access
-
-A `KafkaProxyIngress` resource defines the networking configuration that allows Kafka clients to connect to a `VirtualKafkaCluster`.
-
-It is uniquely associated with a single `KafkaProxy` instance, but it is not uniquely associated with a `VirtualKafkaCluster`; it can be used by multiple `VirtualKafkaCluster` instances.
-
-This example shows a `KafkaProxyIngress` for exposing virtual clusters to Kafka clients running in the same Kubernetes cluster as the proxy.
-
-.Example `KafkaProxyIngress` configuration.
-[source,yaml]
-----
-kind: KafkaProxyIngress
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- namespace: my-proxy
- name: cluster-ip
-spec:
- proxyRef: # <1>
- name: simple
- clusterIP: # <2>
- protocol: TCP # <3>
-----
-<1> The `proxyRef` names the `KafkaProxy` resource that this ingress is part of. It must be in the same namespace as the `KafkaProxyIngress`.
-<2> This ingress uses `clusterIP` networking, which uses Kubernetes `Service` resources with `type: ClusterIP` to configure Kubernetes DNS names for the virtual cluster.
-<3> The protocol is set to accept plain TCP connections. Use `TLS` for encrypted client-proxy communication.
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-kafkaservice-by-bootstrap.adoc b/docs/v0.13.0/_files/modules/configuring/con-kafkaservice-by-bootstrap.adoc
deleted file mode 100644
index fb2bd230..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-kafkaservice-by-bootstrap.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-deploy-a-proxy.adoc
-
-[id='con-configuring-kafkaservice-bootstrap-{context}']
-= Configuration for proxied Kafka clusters
-
-A proxied Kafka cluster is configured in a `KafkaService` resource, which specifies how the proxy connects to the cluster.
-The Kafka cluster may or may not be running in the same Kubernetes cluster as the proxy: Network connectivity is all that's required.
-
-This example shows a `KafkaService` defining how to connect to a Kafka cluster at `kafka.example.com`.
-
-.Example `KafkaService` configuration
-[source,yaml]
-----
-kind: KafkaService
-metadata:
- # ...
-spec:
- bootstrapServers: kafka.example.com:9092 # <1>
- nodeIdRanges: # <2>
- - name: brokers # <3>
- start: 0 # <4>
- end: 5 # <5>
- # ...
-----
-<1> The `bootstrapServers` property is a comma-separated list of addresses in `:` format. Including multiple broker addresses helps clients connect when one is unavailable.
-<2> `nodeIdRanges` declares the IDs of all the broker nodes in the Kafka cluster
-<3> `name` is optional, but specifying it can make errors easier to diagnose.
-<4> The start of the ID range, inclusive.
-<5> The end of the ID range, inclusive.
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-tls-auth-to-kafka-cluster.adoc b/docs/v0.13.0/_files/modules/configuring/con-tls-auth-to-kafka-cluster.adoc
deleted file mode 100644
index 6f8b3513..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-tls-auth-to-kafka-cluster.adoc
+++ /dev/null
@@ -1,36 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-proxy-broker-connection.adoc
-
-[id='con-tls-auth-to-kafka-cluster-{context}']
-= TLS authentication to proxied Kafka clusters
-
-Some Kafka clusters require mutual TLS (mTLS) authentication.
-You can configure the proxy to present a TLS client certificate using the `KafkaService` resource.
-
-The TLS client certificate you provide must have been issued by a Certificate Authority (CA) that's trusted by the proxied cluster.
-
-This example configures a `KafkaService` to use a TLS client certificate stored in a `Secret` named `tls-cert-for-kafka.example.com`.
-
-.Example `KafkaService` configuration with TLS client authentication.
-[source,yaml]
-----
-kind: KafkaService
-metadata:
- # ...
-spec:
- bootstrapServers: kafka.example.com:9092
- tls:
- trustAnchorRef:
- kind: ConfigMap
- name: trusted-cas
- key: trusted-cas.pem
- certificateRef: # <1>
- kind: Secret # <2>
- name: tls-cert-for-kafka.example.com # <3>
- # ...
-----
-<1> The `certificateRef` property identifies the TLS client certificate to use.
-<2> The `kind` is optional and defaults to `Secret`. The `Secret` should have `type: kubernetes.io/tls`.
-<3> The `name` is the name of the resource of the given `kind`. This resource must exist in the same namespace as the `KafkaService`
-
diff --git a/docs/v0.13.0/_files/modules/configuring/con-understanding-kafkaproxyingress-status.adoc b/docs/v0.13.0/_files/modules/configuring/con-understanding-kafkaproxyingress-status.adoc
deleted file mode 100644
index 8e7dd633..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-understanding-kafkaproxyingress-status.adoc
+++ /dev/null
@@ -1,31 +0,0 @@
-[id='con-understanding-kafkaproxyingress-status-{context}']
-= `KafkaProxyIngress` status reporting
-
-== `ResolvedRefs` conditions
-
-When you create a `KafkaProxyIngress`, the operator checks whether a `KafkaProxy` corresponding to the `spec.proxyRef` exists.
-The result is reported in `status.conditions` with a `ResolvedRefs` condition accordingly.
-
-.Example `KafkaProxyIngress` status when `spec.proxyRef` exists
-[source,yaml]
-----
-kind: KafkaProxyIngress
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- name: cluster-ip
- namespace: my-proxy
- generation: 12
-spec:
- # ...
-status:
- observedGeneration: 12 # <1>
- conditions:
- - type: ResolvedRefs # <2>
- status: True # <3>
- observedGeneration: 12
-----
-<1> The `observedGeneration` in the status matches the `metadata.generation`, indicating that the status is up-to-date for the latest `spec`.
-<2> The `ResolvedRefs` condition type reports any issues with referenced resources.
-<3> A status value of `True` means that all referenced resources exist.
-
-A status value of `False` means that the `KafkaProxy` resource is missing. In this case, the condition includes `reason` and `message` properties with more details.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-understanding-virtualkafkacluster-status.adoc b/docs/v0.13.0/_files/modules/configuring/con-understanding-virtualkafkacluster-status.adoc
deleted file mode 100644
index 199d720d..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-understanding-virtualkafkacluster-status.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-[id='con-understanding-virtualkafkacluster-status-{context}']
-= `VirtualKafkaCluster` status reporting
-
-== `ResolvedRefs` conditions
-
-When you create a `VirtualKafkaCluster`, the operator checks whether the following exist:
-
-* A `KafkaProxy` matching `spec.proxyRef`.
-* Each `KafkaProxyIngress` specified in `spec.ingresses`, and whether they refer to the same `KafkaProxy` as the virtual cluster.
-* A `Secret` referred to in the `tls` property.
-
-The result is reported in `status.conditions` with a `ResolvedRefs` condition accordingly.
-
-.Example `VirtualKafkaCluster` status when all referenced resources exist
-[source,yaml]
-----
-kind: VirtualKafkaCluster
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- # ...
- generation: 12
-spec:
- # ...
-status:
- observedGeneration: 12 # <1>
- conditions:
- - type: ResolvedRefs # <2>
- status: True # <3>
- observedGeneration: 12
-----
-<1> The `observedGeneration` in the status matches the `metadata.generation`, indicating that the status is up-to-date for the latest `spec`.
-<2> The `ResolvedRefs` condition type reports any issues with referenced resources.
-<3> A status value of `True` means that all referenced resources exist.
-
-A status value of `False` means that one or more of the referenced resources is missing. In this case, the condition includes `reason` and `message` properties with more details.
-
-== `Accepted` conditions
-
-When a `VirtualKafkaCluster` has a valid spec, the operator attempts to configure the proxy instance accordingly.
-This might not be possible.
-For example, the `spec` may be valid but incompatible with other virtual clusters running in the same proxy instance.
-
-The operator sets a condition type of `Accepted` in `status.conditions` to indicate whether or not a virtual cluster has been successfully configured within a proxy instance.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-mtls.adoc b/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-mtls.adoc
deleted file mode 100644
index 0a9be81a..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-mtls.adoc
+++ /dev/null
@@ -1,35 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-client-proxy-connection.adoc
-
-[id='con-kafka-client-mtls-{context}']
-= Mutual TLS configuration for client-to-proxy connections
-
-You can configure a virtual cluster ingress to request or require Kafka clients to authenticate to the proxy using TLS.
-This configuration is known as mutual TLS (mTLS), because both the client and the proxy authenticate each other using TLS.
-
-.Example `VirtualKafkaCluster` configuration requiring clients to present a trusted certificate
-[source,yaml]
-----
-kind: VirtualKafkaCluster
-metadata:
- # ...
-spec:
- # ...
- ingresses:
- - ingressRef:
- name: cluster-ip
- tls:
- certificateRef:
- # ...
- trustAnchorRef: # <1>
- kind: ConfigMap # <2>
- name: trusted-cas # <3>
- key: trusted-cas.pem # <4>
- tlsClientAuthentication: REQUIRED <5>
-----
-<1> References a separate Kubernetes resource containing the trusted CA certificates.
-<2> The `kind` is optional and defaults to `ConfigMap`.
-<3> Name of the resource of the given `kind`, which must exist in the same namespace as the `VirtualKafkaCluster`.
-<4> Key identifying the entry in the given resource. The corresponding value must be a set of CA certificates. Supported formats for the bundle are: `PEM`, `PKCS#12`, and `JKS`.
-<5> Specifies whether client authentication is required (`REQUIRED`), requested (`REQUESTED`), or disabled (`NONE`). If a `trustAnchorRef` is specified, the default is `REQUIRED`.
diff --git a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tcp.adoc b/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tcp.adoc
deleted file mode 100644
index 5f730c75..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tcp.adoc
+++ /dev/null
@@ -1,62 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-deploy-a-proxy.adoc
-
-[id='con-configuring-virtualkafkacluster-{context}']
-= Virtual cluster configuration for in-cluster access without TLS
-
-A `VirtualKafkaCluster` resource defines a logical Kafka cluster that is accessible to clients over the network.
-
-The virtual cluster references the following:
-
-* A `KafkaProxy` resource that the proxy is associated with.
-* One or more `KafkaProxyIngress` resources that expose the virtual cluster to Kafka clients.
-* A `KafkaService` resource that defined the backend Kafka cluster.
-* Zero or more `KafkaProtocolFilter` resources that apply filters to the Kafka protocol traffic passing between clients and the backend Kafka cluster.
-
-This example shows a `VirtualKafkaCluster`, exposing it to Kafka clients running on the same Kubernetes cluster.
-It uses plain TCP (as opposed to TLS) as the transport protocol.
-
-.Example `VirtualKafkaCluster` configuration
-[source,yaml]
-----
-kind: VirtualKafkaCluster
-apiVersion: kroxylicious.io/v1alpha1
-metadata:
- name: my-cluster
- namespace: my-proxy
-spec:
- proxyRef: # <1>
- name: simple
- targetKafkaServiceRef: # <2>
- name: my-cluster
- ingresses:
- - ingressRef: # <3>
- name: cluster-ip
-----
-<1> The `proxyRef` names the `KafkaProxy` hosting with this virtual cluster.
- It must be in the same namespace as the `VirtualKafkaCluster`.
-<2> The `KafkaService` that is proxied by the virtual cluster.
- It must be in the same namespace as the `VirtualKafkaCluster`.
-<3> Ingresses to expose the virtual cluster.
- Each ingress names a `KafkaProxyIngress` which must be in the same namespace as the `VirtualKafkaCluster`.
-
-// Let's look at what the referenced `KafkaProxyIngress` would look like.
-//
-// .Example `KafkaProxyIngress` configuration.
-// [source,yaml]
-// ----
-// kind: KafkaProxyIngress
-// apiVersion: kroxylicious.io/v1alpha1
-// metadata:
-// name: cluster-ip
-// namespace: my-proxy
-// spec:
-// proxyRef: # <1>
-// name: simple
-// clusterIP: # <2>
-// protocol: TCP # <3>
-// ----
-// <1> The ingress needs to refer to the same `KafkaProxy` resource as the `VirtualKafkaCluster`.
-// <2> We use `clusterIP` for on-Kubernetes access.
-// <3> The ingress uses `TCP` as the transport protocol.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tls-cipher.adoc b/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tls-cipher.adoc
deleted file mode 100644
index adc35b73..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tls-cipher.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-client-proxy-connection.adoc
-
-[id='con-kafka-client-tls-cipher-{context}']
-= TLS cipher suite configuration for client-to-proxy connections
-
-include::../../snippets/snip-tls-cipher-suite.adoc[]
-
-You can restrict which TLS cipher suites the proxy uses when negotiating client-to-proxy connections by configuring the `cipherSuites` property.
-
-.Example `VirtualKafkaCluster` configuration using cipherSuites to allow specific ciphers
-[source,yaml]
-----
-kind: VirtualKafkaCluster
-metadata:
- # ...
-spec:
- # ...
- ingresses:
- - ingressRef:
- name: cluster-ip
- tls:
- certificateRef:
- # ...
- cipherSuites: # <1>
- allow: # <2>
- - TLS_AES_128_GCM_SHA256
- - TLS_AES_256_GCM_SHA384
-
-----
-<1> Configures the cipher suites used by the proxy.
-<2> Lists the cipher suites explicitly allowed for TLS negotiation.
-
-Alternatively, you can use `deny` to specify cipher suites to exclude.
-
-The names of the cipher suites supported depend on the JVM in the proxy container image.
-See {cipherSuiteNames}.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tls-protocol.adoc b/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tls-protocol.adoc
deleted file mode 100644
index d5313aaf..00000000
--- a/docs/v0.13.0/_files/modules/configuring/con-virtualkafkacluster-tls-protocol.adoc
+++ /dev/null
@@ -1,36 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/assemblies/assembly-operator-secure-client-proxy-connection.adoc
-
-[id='con-kafka-client-tls-protocol-{context}']
-= TLS version configuration for client-to-proxy connections
-
-include::../../snippets/snip-tls-protocol-versions.adoc[]
-
-You can restrict which TLS protocol versions the proxy supports for client-to-proxy connections by configuring the `protocols` property.
-
-.Example `VirtualKafkaCluster` with restricted TLS protocol versions
-[source,yaml]
-----
-kind: VirtualKafkaCluster
-metadata:
- # ...
-spec:
- # ...
- ingresses:
- - ingressRef:
- name: cluster-ip
- tls:
- certificateRef:
- # ...
- protocols: # <1>
- allow: # <2>
- - TLSv1.3
-----
-<1> Configures the TLS protocol versions used by the proxy.
-<2> Lists the protocol versions explicitly allowed for TLS negotiation.
-
-Alternatively, you can use `deny` to specify protocol versions to exclude.
-
-The names of the TLS protocol versions supported depend on the JVM in the proxy container image.
-See {tlsProtocolNames}.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/configuring/ref-configuring-proxy-example.adoc b/docs/v0.13.0/_files/modules/configuring/ref-configuring-proxy-example.adoc
deleted file mode 100644
index b96717d4..00000000
--- a/docs/v0.13.0/_files/modules/configuring/ref-configuring-proxy-example.adoc
+++ /dev/null
@@ -1,68 +0,0 @@
-[id='ref-configuring-proxy-example-{context}']
-= Example Kroxylicious configuration
-
-* Virtual clusters that represent the Kafka clusters
-* Network addresses for broker communication in a Kafka cluster
-* Filters to introduce additional functionality to the Kafka deployment
-
-In this example, configuration for the Record Encryption filter is shown.
-
-[id='con-deploying-upstream-tls-{context}']
-.Example Kroxylicious configuration
-[source,yaml]
-----
-filterDefinitions: # <1>
- - name: encryption
- type: RecordEncryption # <2>
- config: # <3>
- kms: VaultKmsService
- kmsConfig:
- vaultTransitEngineUrl: https://vault.vault.svc.cluster.local:8200/v1/transit
- vaultToken:
- passwordFile: /opt/proxy/server/token.txt
- tls: # <4>
- key:
- storeFile: /opt/cert/server.p12
- storePassword:
- passwordFile: /opt/cert/store.password
- keyPassword:
- passwordFile: /opt/cert/key.password
- storeType: PKCS12
- selector: TemplateKekSelector
- selectorConfig:
- template: "$(topicName)"
-defaultFilters:
- - encryption
-virtualClusters: # <5>
- - name: my-cluster-proxy # <6>
- targetCluster:
- bootstrapServers: my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9093 # <7>
- tls: # <8>
- trust:
- storeFile: /opt/proxy/trust/ca.p12
- storePassword:
- passwordFile: /opt/proxy/trust/ca.password
- gateways: # <9>
- - name: mygateway
- sniHostIdentifiesNode: # <10>
- bootstrapAddress: my-cluster-proxy.kafka:9092 # <11>
- advertisedBrokerAddressPattern: broker$(nodeId).my-cluster-proxy.kafka
- tls: # <12>
- key:
- storeFile: /opt/proxy/server/key-material/keystore.p12
- storePassword:
- passwordFile: /opt/proxy/server/keystore-password/storePassword
-----
-<1> A list of named filter configurations.
-<2> The type of filter, which is the Record Encryption filter using Vault as the KMS in this example.
-<3> The configuration specific to the type of filter.
-<4> If required, you can also specify the credentials for TLS authentication with the KMS, with key names under which TLS certificates are stored.
-<5> Virtual cluster configuration.
-<6> The name of the virtual cluster.
-<7> The bootstrap address of the target physical Kafka Cluster being proxied.
-<8> TLS configuration for the connection to the target cluster.
-<9> The gateway of the virtual cluster defining how the virtual cluster is presented to the network.
-<10> The identification scheme used to route traffic to brokers, which can be `sniHostIdentifiesNode` or `portIdentifiesNode`.
-<11> The hostname and port of the bootstrap used by the Kafka clients to connect to the gateway. The hostname must be resolved by the clients.
-<12> TLS encryption used by the gateway for securing connections with the clients.
-
diff --git a/docs/v0.13.0/_files/modules/install/con-install-prereqs.adoc b/docs/v0.13.0/_files/modules/install/con-install-prereqs.adoc
deleted file mode 100644
index a4fd8b7c..00000000
--- a/docs/v0.13.0/_files/modules/install/con-install-prereqs.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-// Module included in the following assemblies:
-//
-// assemblies/assembly-operator-install.adoc
-
-[id='install-prereqs-{context}']
-= Install prerequisites
-
-To install Kroxylicious, you will need the following:
-
-ifndef::OpenShiftOnly[]
-* A Kubernetes {KubernetesVersionMinimum} or later cluster.
-+
-* The `kubectl` command-line tool to be installed and configured to connect to the running cluster.
-
-For more information on the tools available for running Kubernetes, see {KubeTools} in the Kubernetes documentation.
-
-endif::OpenShiftOnly[]
-
-ifdef::OpenShiftOnly[]
-[discrete]
-
-* An OpenShift {OpenShiftVersionMinimum} or later cluster.
-
-* The `oc` command-line tool is installed and configured to connect to the running cluster.
-
-== `oc` and `kubectl` commands
-
-The `oc` command functions as an alternative to `kubectl`.
-In almost all cases the example `kubectl` commands used in this guide can be done using `oc` simply by replacing the command name (options and arguments remain the same).
-
-In other words, instead of using:
-
-[source,shell,subs=+quotes]
-kubectl apply -f _your-file_
-
-when using OpenShift you can use:
-
-[source,shell,subs=+quotes]
-oc apply -f _your-file_
-
-// NOTE: As an exception to this general rule, `oc` uses `oc adm` subcommands for _cluster management_ functionality,
-// whereas `kubectl` does not make this distinction.
-// For example, the `oc` equivalent of `kubectl taint` is `oc adm taint`.
-
-endif::OpenShiftOnly[]
diff --git a/docs/v0.13.0/_files/modules/install/con-install-product-downloads.adoc b/docs/v0.13.0/_files/modules/install/con-install-product-downloads.adoc
deleted file mode 100644
index e5e1c099..00000000
--- a/docs/v0.13.0/_files/modules/install/con-install-product-downloads.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-// Module included in the following assemblies:
-//
-// assemblies/assembly-operator-install.adoc
-
-[id='downloads-{context}']
-= Kroxylicious release artifacts
-
-[role="_abstract"]
-To use YAML manifest files to install Kroxylicious, download {OperatorAssetZipFileName} or {OperatorAssetTgzFileName} file from the {OperatorDownloadUrl}, and extract the files as appropriate (for example using `unzip` or `tar -xzf`).
-
-Each of these archives contains:
-
-Installation Files:: In the `install` directory are the YAML manifests needed to install the operator.
-
-Examples:: In the `examples` directory are examples of the custom resources which can be used to deploy a proxy once the operator has been installed.
diff --git a/docs/v0.13.0/_files/modules/install/proc-install-operator.adoc b/docs/v0.13.0/_files/modules/install/proc-install-operator.adoc
deleted file mode 100644
index 5ed2458d..00000000
--- a/docs/v0.13.0/_files/modules/install/proc-install-operator.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-// Module included in the following assemblies:
-//
-// assemblies/assembly-operator-install.adoc
-
-[id='install-cluster-operator-{context}']
-= Installing the Kroxylicious Operator
-
-[role="_abstract"]
-This procedure shows how to install the Kroxylicious Operator in your Kubernetes cluster.
-
-.Prerequisites
-
-* You need an account with permission to create and manage `CustomResourceDefinition` and RBAC (`ClusterRole`) resources.
-* You have downloaded one of {OperatorAssetZipFileName} or {OperatorAssetTgzFileName} and extracted the contents into the current directory.
-
-.Procedure
-
-. Edit the Kroxylicious installation files to use the namespace the operator is going to be installed into.
-+
-For example, in this procedure the operator is installed into the namespace `my-kroxylicious-operator-namespace`.
-+
-include::../../snippets/snip-operator-namespace-sed.adoc[]
-
-. Deploy the Kroxylicious operator:
-+
-[source,shell,subs="+quotes,attributes+"]
-kubectl create -f install
-
-. Check the status of the deployment:
-+
-[source,shell,subs="+quotes"]
-----
-kubectl get deployments -n my-kroxylicious-operator-namespace
-----
-+
-.Output shows the deployment name and readiness
-[source,shell,subs="+quotes"]
-----
-NAME READY UP-TO-DATE AVAILABLE
-kroxylicious-operator 1/1 1 1
-----
-+
-`READY` shows the number of replicas that are ready/expected.
-The deployment is successful when the `AVAILABLE` output shows `1`.
diff --git a/docs/v0.13.0/_files/modules/monitoring/con-operator-ingesting-metrics.adoc b/docs/v0.13.0/_files/modules/monitoring/con-operator-ingesting-metrics.adoc
deleted file mode 100644
index f9952f16..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/con-operator-ingesting-metrics.adoc
+++ /dev/null
@@ -1,21 +0,0 @@
-// file included in the following:
-//
-// assembly-operator-monitoring.adoc
-
-[id='con-operator-ingesting-metrics-{context}']
-= Ingesting metrics
-
-[role="_abstract"]
-Metrics from the Kroxylicious Proxy and Kroxylicious Operator can be ingested into your Prometheus instance.
-The proxy and the operator each expose an HTTP endpoint for Prometheus metrics at the `/metrics` address.
-The endpoint does not require authentication.
-
-For the Proxy, the port that exposes the scrape endpoint is named `management`.
-For the Operator, the port is named `http`.
-
-Prometheus can be configured to ingest the metrics from the scrape endpoints.
-
-This guide assumes you are using the https://prometheus-operator.dev/[Prometheus Operator] to configure Prometheus.
-
-include::./proc-operator-ingesting-metrics-operator.adoc[leveloffset=+1]
-include::./proc-operator-ingesting-metrics-proxy.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/modules/monitoring/con-operator-setting-log-levels.adoc b/docs/v0.13.0/_files/modules/monitoring/con-operator-setting-log-levels.adoc
deleted file mode 100644
index 66560c1b..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/con-operator-setting-log-levels.adoc
+++ /dev/null
@@ -1,28 +0,0 @@
-// file included in the following:
-//
-// assembly-operator-monitoring.adoc
-
-[id='con-operator-setting-log-levels-{context}']
-= Setting log levels
-
-[role="_abstract"]
-
-You can independently control the logging level of both the Kroxylicious Operator and the Kroxylicious Proxy.
-
-In both cases, logging levels are controlled using two environment variables:
-
-* `KROXYLICIOUS_APP_LOG_LEVEL` controls the logging of the application (`io.kroxylicious` loggers). It defaults to `INFO`.
-* `KROXYLICIOUS_ROOT_LOG_LEVEL` controls the logging level at the root. It defaults to `WARN`.
-
-When trying to diagnose a problem, start first by raising the logging level of `KROXYLICIOUS_APP_LOG_LEVEL`.
-If more detailed diagnostics are required, try raising the `KROXYLICIOUS_ROOT_LOG_LEVEL`. Both the proxy and operator
-use Apache Log4J2 and use logging levels understood by it: `TRACE`, `DEBUG`, `INFO`, `WARN`, and `ERROR`.
-
-WARNING: WARNING: Running the operator or the proxy at elevated logging levels, such as `DEBUG` or `TRACE`, can generate a large volume of logs, which may consume significant storage and affect performance.
-Run at these levels only as long as necessary.
-
-include::./proc-operator-setting-log-levels-proxy.adoc[leveloffset=+1]
-ifdef::include-olm[]
-include::./proc-operator-setting-log-levels-operator-olm.adoc[leveloffset=+1]
-endif::[]
-include::./proc-operator-setting-log-levels-operator-bundle.adoc[leveloffset=+1]
diff --git a/docs/v0.13.0/_files/modules/monitoring/con-prometheus-metrics-operator.adoc b/docs/v0.13.0/_files/modules/monitoring/con-prometheus-metrics-operator.adoc
deleted file mode 100644
index 7c9b21b2..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/con-prometheus-metrics-operator.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='con-prometheus-metrics-operator-{context}']
-= Overview of operator metrics
-
-[role="_abstract"]
-
-The Kroxylicious Operator is implemented using the {josdk}[Java Operator SDK].
-The Java Operator SDK exposes metrics that allow its behavior to be understood.
-These metrics are enabled by default in the Kroxylicious Operator.
-
-Refer to the {josdk-metrics}[Java Operator SDK metric documentation] to learn more about metrics.
diff --git a/docs/v0.13.0/_files/modules/monitoring/con-prometheus-metrics-proxy.adoc b/docs/v0.13.0/_files/modules/monitoring/con-prometheus-metrics-proxy.adoc
deleted file mode 100644
index 69a678dd..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/con-prometheus-metrics-proxy.adoc
+++ /dev/null
@@ -1,140 +0,0 @@
-// file included in the following:
-//
-// kroxylicious-operator/index.adoc
-
-[id='con-prometheus-metrics-proxy-{context}']
-= Overview of proxy metrics
-
-[role="_abstract"]
-
-The proxy provides metrics for both connections and messages.
-These metrics are categorized into downstream (client-side) and upstream (broker-side) groups
-They allow users to assess the impact of the proxy and its filters on their Kafka system.
-
-* Connection metrics count the connections made from the downstream (incoming connections from the clients) and the connection made by the proxy to upstream (outgoing connections to the Kafka brokers).
-* Message metrics count the number of {kafka-protocol}#protocol_messages[Kafka protocol request and response messages] that flow through the proxy.
-
-== Connection metrics
-
-Connection metrics count the TCP connections made from the client to the proxy (`kroxylicious_client_to_proxy_request_total`) and from the proxy to the broker (`kroxylicious_proxy_to_server_connections_total`).
-These metrics count connection _attempts_, so the connection count is incremented even if the connection attempt ultimately fails.
-
-In addition to the count metrics, there are error metrics.
-* If an error occurs whilst the proxy is accepting a connection from the client the `kroxylicious_client_to_proxy_errors_total` metric is incremented by one.
-* If an error occurs whilst the proxy is attempting a connection to a broker the `kroxylicious_proxy_to_server_errors_total` metric is incremented by one.
-
-Connection and connection error metrics include the following labels: `virtual_cluster` (the virtual cluster's name) and `node_id` (the broker's node ID).
-When the client connects to the boostrap endpoint of the virtual cluster, a node ID value of `bootstrap` is recorded.
-
-The `kroxylicious_client_to_proxy_errors_total` metric also counts connection errors that occur before a virtual cluster has been identified.
-For these specific errors, the `virtual_cluster` and `node_id` labels are set to an empty string ("").
-
-NOTE: Error conditions signaled _within_ the Kafka protocol response (such as `RESOURCE_NOT_FOUND` or `UNKNOWN_TOPIC_ID`) are not classed as errors by these metrics.
-
-.Connection metrics for client and broker interactions
-|===
-|Metric Name |Type |Labels|Description
-
-|`kroxylicious_client_to_proxy_connection_total`
-|Counter
-|`virtual_cluster`, `node_id`
-|Incremented by one every time a connection is accepted from a client by the proxy. +
- This metric counts all connection attempts that reach the proxy, even those that end in error.
-
-|`kroxylicious_client_to_proxy_errors_total`
-|Counter
-|`virtual_cluster`, `node_id`
-|Incremented by one every time a connection is closed due to any downstream error.
-
-|`kroxylicious_proxy_to_server_connections_total`
-|Counter
-|`virtual_cluster`, `node_id`
-|Incremented by one every time a connection is made to the server from the proxy. +
- This metric counts all connections attempted to the broker, even those that end in error.
-
-|`kroxylicious_proxy_to_server_errors_total`
-|Counter
-|`virtual_cluster`, `node_id`
-|Incremented by one every time a connection is closed due to any upstream error.
-|===
-
-== Message metrics
-
-Message metrics count, and record the sizes of, the Kafka protocol requests and responses that flow through the proxy.
-
-Use these metrics to help understand:
-* the number of messages flowing through the proxy.
-* the overall volume of data through the proxy.
-* the effect the filters are having on the messages.
-
-* Downstream metrics
-** `kroxylicious_client_to_proxy_request_total` counts requests as they arrive from the client.
-** `kroxylicious_proxy_to_client_response_total` counts responses as they are returned to the client.
-** `kroxylicious_client_to_proxy_request_size_bytes` is incremented by the size of each request as it arrives from the client.
-** `kroxylicious_proxy_to_client_response_size_bytes` is incremented by the size of each response as it is returned to the client.
-
-* Upstream metrics
-** `kroxylicious_proxy_to_server_request_total` counts requests as they go to the broker.
-** `kroxylicious_proxy_to_server_response_total` counts responses as they are returned by the broker.
-** `kroxylicious_proxy_to_server_request_size_bytes` is incremented by the size of each request as it goes to the broker.
-** `kroxylicious_proxy_to_server_response_size_bytes` is incremented by the size of each response as it is returned by the broker.
-
-The size recorded is the encoded size of the protocol message. It includes the 4 byte {kafka-protocol}#protocol_common[message size].
-
-Filters can alter the flow of messages through the proxy or the content of the message.
-This is apparent through the metrics.
-* If a filter sends a short-circuit, or closes a connection the downstream message counters will exceed the upstream counters.
-* If a filter changes the size of the message, the downstream size metrics will be different to the upstream size metrics.
-
-.Downstream and upstream message metrics in the proxy
-image::monitoring-message-counters.svg["Conceptual diagram showing the downstream and upstream message metrics within the proxy, illustrating how they respond to message transit through it."]
-
-Message metrics include the following labels: `virtual_cluster` (the virtual cluster's name), `node_id` (the broker's node ID), `api_key` (the message type), `api_version`, and `decoded` (a flag indicating if the message was decoded by the proxy).
-
-When the client connects to the boostrap endpoint of the virtual cluster, metrics are recorded with a node ID value of `bootstrap`.
-
-.Kafka message metrics for proxy request and response flow
-|===
-|Metric Name |Type |Labels|Description
-
-|`kroxylicious_client_to_proxy_request_total`
-|Counter
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by one every time a request arrives at the proxy from a client.
-
-|`kroxylicious_proxy_to_server_request_total`
-|Counter
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by one every time a request goes from the proxy to a server.
-
-|`kroxylicious_server_to_proxy_response_total`
-|Counter
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by one every time a response arrives at the proxy from a server.
-
-|`kroxylicious_proxy_to_client_response_total`
-|Counter
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by one every time a response goes from the proxy to a client.
-
-|`kroxylicious_client_to_proxy_request_total`
-|Distribution
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by the size of the message each time a request arrives at the proxy from a client.
-
-|`kroxylicious_proxy_to_server_request_total`
-|Distribution
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by the size of the message each time a request goes from the proxy to a server.
-
-|`kroxylicious_server_to_proxy_response_total`
-|Distribution
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by the size of the message each time a response arrives at the proxy from a server.
-
-|`kroxylicious_proxy_to_client_response_total`
-|Distribution
-|`virtual_cluster`, `node_id`, `api_key`, `api_version`, `decoded`
-|Incremented by the size of the message each time a response goes from the proxy to a client.
-
-|===
diff --git a/docs/v0.13.0/_files/modules/monitoring/con-proxy-ingesting-metrics.adoc b/docs/v0.13.0/_files/modules/monitoring/con-proxy-ingesting-metrics.adoc
deleted file mode 100644
index 76bbc901..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/con-proxy-ingesting-metrics.adoc
+++ /dev/null
@@ -1,23 +0,0 @@
-// file included in the following:
-//
-// assembly-proxy-monitoring.adoc
-
-[id='con-proxy-ingesting-metrics-{context}']
-= Ingesting metrics
-
-[role="_abstract"]
-Metrics from the Kroxylicious Proxy can be ingested into your Prometheus instance.
-
-Configure the https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config[`scrape_configs`] property to enable
-Prometheus to scrape the monitors from your proxy instances.
-
-.Example Prometheus scrape config
-
-[source]
-----
-scrape_configs:
- - job_name: 'kroxylicious'
- static_configs:
- - targets: ['proxyhost:9190'] # <1>
-----
-<1> The host that is running the kroxylicious instance and the port number assigned to management.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/monitoring/con-proxy-integrating-micrometer.adoc b/docs/v0.13.0/_files/modules/monitoring/con-proxy-integrating-micrometer.adoc
deleted file mode 100644
index e95fa14e..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/con-proxy-integrating-micrometer.adoc
+++ /dev/null
@@ -1,96 +0,0 @@
-// file included in the following:
-//
-// assembly-proxy-monitoring.adoc
-
-[id='con-proxy-integrating-micrometer-{context}']
-= Integrating Micrometer
-Kroxylicious integrates with https://micrometer.io/docs[Micrometer] for gathering metrics.
-
-Micrometer provides a simple facade over instrumentation clients for popular observability systems, allowing you to instrument your JVM-based application code without vendor lock-in.
-The following example shows how to define the `CommonTagsHook` and `StandardBindersHook` types to add a label to metrics and register a JVM metrics binder.
-
-.Example proxy configuration for Micrometer integration
-[source,yaml]
-----
-management:
- endpoints:
- prometheus: {}
-micrometer:
- - type: "CommonTagsHook" # <1>
- config:
- commonTags:
- zone: "euc-1a" # <2>
- - type: "StandardBindersHook" # <3>
- config:
- binderNames:
- - "JvmGcMetrics" # <4>
-----
-<1> Specifies the `CommonTagsHook` type to add common tags to all metrics.
-<2> Adds common tag zone `euc-1a` to all metrics in the global registry included with Micrometer, which appears as a label in Prometheus.
-<3> Specifies the `StandardBindersHook` type to register standard Micrometer binders.
-<4> Registers the `JvmGcMetrics` binder with the global registry.
-
-Prometheus is connected to the Micrometer global registry, so filters can record metrics against it as part of the Prometheus scrape data.
-
-Using the `curl localhost:9190/metrics` command shows metrics as follows:
-
-.Example metrics returned from request
-[source,shell]
-----
-jvm_gc_memory_allocated_bytes_total{zone="euc-1a",} 0.0
-----
-
-== Common tags
-
-Add common tags for metrics to appear as labels in the Prometheus scrape.
-
-.Example common tag configuration
-[source,yaml]
-----
-- type: "CommonTagsHook"
- config:
- commonTags:
- zone: "euc-1a"
- owner: "team-a"
-----
-
-== Standard binders
-
-Micrometer uses the concept of meter binders to register metrics that provide information about the state of some aspect of the application or its container.
-By registering standard binders included with Micrometer, you can expose metrics about the JVM and system, such as JVM memory usage and garbage collection.
-
-.Example binders configuration
-[source,yaml]
-----
-micrometer:
- - type: "StandardBindersHook"
- config:
- binderNames:
- - "JvmGcMetrics"
- - "JvmHeapPressureMetrics"
-----
-
-.Standard binders available with Micrometer
-[cols="2m,4m",options="header"]
-|===
-
-| Name | Micrometer class
-| ClassLoaderMetrics | io.micrometer.core.instrument.binder.jvm.ClassLoaderMetrics
-| JvmCompilationMetrics | io.micrometer.core.instrument.binder.jvm.JvmCompilationMetrics
-| JvmGcMetrics | io.micrometer.core.instrument.binder.jvm.JvmGcMetrics
-| JvmHeapPressureMetrics | io.micrometer.core.instrument.binder.jvm.JvmHeapPressureMetrics
-| JvmInfoMetrics | io.micrometer.core.instrument.binder.jvm.JvmInfoMetrics
-| JvmMemoryMetrics | io.micrometer.core.instrument.binder.jvm.JvmMemoryMetrics
-| JvmThreadMetrics | io.micrometer.core.instrument.binder.jvm.JvmThreadMetrics
-| FileDescriptorMetrics | io.micrometer.core.instrument.binder.system.FileDescriptorMetrics
-| ProcessorMetrics | io.micrometer.core.instrument.binder.system.ProcessorMetrics
-| UptimeMetrics | io.micrometer.core.instrument.binder.system.UptimeMetrics
-
-|===
-
-== Using Micrometer with filters
-
-Use the static methods of https://www.javadoc.io/doc/io.micrometer/micrometer-core/1.10.5/io/micrometer/core/instrument/Metrics.html[Micrometer Metrics^] to register metrics with the global registry.
-
-Alternatively, use `Metrics.globalRegistry` to get a reference to the global registry.
-Metrics registered this way are automatically available through the Prometheus scrape endpoint.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-operator-ingesting-metrics-operator.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-operator-ingesting-metrics-operator.adoc
deleted file mode 100644
index 0dbd526c..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-operator-ingesting-metrics-operator.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-// file included in the following:
-//
-// con-operator-ingesting-metrics.adoc
-
-[id='proc-operator-ingesting-metrics-operator{context}']
-= Ingesting operator metrics
-
-[role="_abstract"]
-This procedure describes how to ingest metrics from the Kroxylicious Operator into Prometheus.
-
-.Prerequisites
-
-* Kroxylicious Operator is installed.
-* https://prometheus-operator.dev/[Prometheus Operator] is installed, and a Prometheus instance has been created using the https://prometheus-operator.dev/docs/api-reference/api/#monitoring.coreos.com/v1.Prometheus[`Prometheus` custom resource].
-
-.Procedure
-
-. Apply the PodMonitor configuration:
-+
-[source,yaml]
-----
-apiVersion: monitoring.coreos.com/v1
-kind: PodMonitor
-metadata:
- name: proxy
-spec:
- selector:
- matchLabels:
- app.kubernetes.io/name: kroxylicious
- app.kubernetes.io/component: operator
- podMetricsEndpoints:
- - path: /metrics
- port: http
-----
-+
-The Prometheus Operator reconfigures Prometheus automatically.
-Prometheus begins to regularly to scrape the Kroxylicious Operator's metric.
-
-. Check the metrics are being ingested using a PromQL query such as:
-+
-[source]
-----
-operator_sdk_reconciliations_queue_size_kafkaproxyreconciler{kind="KafkaProxy", group="kroxylicious.io"}
-----
-
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-operator-ingesting-metrics-proxy.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-operator-ingesting-metrics-proxy.adoc
deleted file mode 100644
index 9ffb57c0..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-operator-ingesting-metrics-proxy.adoc
+++ /dev/null
@@ -1,46 +0,0 @@
-// file included in the following:
-//
-// con-operator-ingesting-metrics.adoc
-
-
-[id='proc-operator-ingesting-metrics-proxy{context}']
-= Ingesting proxy metrics
-
-[role="_abstract"]
-This procedure describes how to ingest metrics from the Kroxylicious Proxy into Prometheus.
-
-.Prerequisites
-
-* Kroxylicious Operator is installed.
-* https://prometheus-operator.dev/[Prometheus Operator] is installed, and a Prometheus instance has been created using the https://prometheus-operator.dev/docs/api-reference/api/#monitoring.coreos.com/v1.Prometheus[`Prometheus` custom resource].
-* An instance of Kroxylicious deployed by the operator.
-
-.Procedure
-
-. Apply the PodMonitor configuration:
-+
-[source,yaml]
-----
-apiVersion: monitoring.coreos.com/v1
-kind: PodMonitor
-metadata:
- name: proxy
-spec:
- selector:
- matchLabels:
- app.kubernetes.io/application: kroxylicious
- app.kubernetes.io/component: proxy
- podMetricsEndpoints:
- - path: /metrics
- port: management
-----
-+
-The Prometheus Operator reconfigures Prometheus automatically.
-Prometheus begins to regularly to scrape the proxy's metric.
-
-. Check the metrics are being ingested using a PromQL query such as:
-+
-[source]
-----
-kroxylicious_build_info
-----
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-operator-bundle.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-operator-bundle.adoc
deleted file mode 100644
index eff97fc5..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-operator-bundle.adoc
+++ /dev/null
@@ -1,59 +0,0 @@
-// file included in the following:
-//
-// con-operator-setting-log-levels.adoc
-
-[id='proc-operator-setting-log-levels-operator-bundle-{context}']
-
-= Overriding the operator logging level (operator installed by bundle)
-
-[role="_abstract"]
-This procedure describes how to override the logging level of the Kroxylicious Operator.
-It applies when the operator was installed from the YAML bundle.
-
-.Prerequisites
-
-* Kroxylicious Operator installed from the YAML bundle.
-
-.Procedure
-
-. Apply the `KROXYLICIOUS_APP_LOG_LEVEL` or `KROXYLICIOUS_ROOT_LOG_LEVEL` environment variable to the operator's Kubernetes Deployment:
-+
-[source,bash]
-----
-kubectl set env -n kroxylicious-operator deployment kroxylicious-operator KROXYLICIOUS_APP_LOG_LEVEL=DEBUG
-----
-+
-Kubernetes recreates the operator pod automatically.
-
-. Verify that the new logging level has taken affect:
-+
-[source,bash]
-----
-kubectl logs -f -n kroxylicious-operator deployment/kroxylicious-operator
-----
-
-== Reverting operator logging levels
-
-This procedure describes how to revert the logging level of the Kroxylicious Operator back to its defaults.
-
-.Prerequisites
-
-* Kroxylicious Operator installed from the YAML bundle.
-
-.Procedure
-
-. Remove the `KROXYLICIOUS_APP_LOG_LEVEL` or `KROXYLICIOUS_ROOT_LOG_LEVEL` environment variable from the proxy's Kubernetes Deployment:
-+
-[source,bash]
-----
-kubectl set env -n kroxylicious-operator deployment kroxylicious-operator KROXYLICIOUS_APP_LOG_LEVEL-
-----
-+
-Kubernetes recreates the operator pod automatically
-
-. Verify that the logging level has reverted to its default:
-+
-[source,bash]
-----
-kubectl logs -f -n kroxylicious-operator deployment/kroxylicious-operator
-----
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-operator-olm.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-operator-olm.adoc
deleted file mode 100644
index f6ba6882..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-operator-olm.adoc
+++ /dev/null
@@ -1,66 +0,0 @@
-// file included in the following:
-//
-// con-operator-setting-log-levels.adoc
-
-[id='proc-operator-setting-log-levels-operator-olm-{context}']
-
-= Overriding operator logging levels (operator installed by OLM)
-
-[role="_abstract"]
-This procedure describes how to override the logging level of the Kroxylicious Operator.
-It applies when the operator was installed by OLM.
-
-.Prerequisites
-
-* Kroxylicious Operator installed using OLM.
-
-.Procedure
-
-. Identify the name of the Subscription resource that has installed the operator and its namespace:
-+
-[source,bash]
-----
-kubectl get subscriptions.operators.coreos.com --all-namespaces | grep kroxylicious
-----
-
-. Apply the `KROXYLICIOUS_APP_LOG_LEVEL` or `KROXYLICIOUS_ROOT_LOG_LEVEL` environment variable to the Subscription:
-+
-[source,bash]
-----
-kubectl patch subscription -n -p '{"spec":{"config":{"env":[{"name":"KROXYLICIOUS_APP_LOG_LEVEL","value":"DEBUG"}]}}}' --type=merge
-----
-+
-Kubernetes recreates the operator pod automatically.
-
-. Verify that the new logging level has taken affect:
-+
-[source,bash]
-----
-kubectl logs -f -n deployment/kroxylicious-operator
-----
-
-== Reverting operator logging levels
-
-This procedure describes how to revert the logging level of the Kroxylicious Operator back to its defaults.
-
-.Prerequisites
-
-* Kroxylicious Operator installed using OLM.
-
-.Procedure
-
-. Remove the `KROXYLICIOUS_APP_LOG_LEVEL` or `KROXYLICIOUS_ROOT_LOG_LEVEL` environment variable from the Subcription:
-+
-[source,bash]
-----
-kubectl patch subscription -p '{"spec":{"config":{"env":[]}}}' --type=merge
-----
-+
-Kubernetes recreates the operator pod automatically
-
-. Verify that the logging level has reverted to its default:
-+
-[source,bash]
-----
-kubectl logs -f -n deployment/kroxylicious-operator
-----
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-proxy.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-proxy.adoc
deleted file mode 100644
index 185e5953..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-operator-setting-log-levels-proxy.adoc
+++ /dev/null
@@ -1,59 +0,0 @@
-// file included in the following:
-//
-// con-operator-setting-log-levels.adoc
-
-[id='proc-operator-setting-log-levels-proxy{context}']
-
-= Overriding proxy logging levels
-
-[role="_abstract"]
-This procedure describes how to override the logging level of the Kroxylicious Proxy.
-
-.Prerequisites
-
-* An instance of Kroxylicious deployed by the Kroxylicious Operator.
-
-.Procedure
-
-. Apply the `KROXYLICIOUS_APP_LOG_LEVEL` or `KROXYLICIOUS_ROOT_LOG_LEVEL` environment variable to the proxy's Kubernetes `Deployment` resource:
-+
-[source,bash]
-----
-kubectl set env -n deployment KROXYLICIOUS_APP_LOG_LEVEL=DEBUG
-----
-+
-The `Deployment` resource has the same name as the `KafkaProxy`.
-+
-Kubernetes recreates the proxy pod automatically.
-
-. Verify that the new logging level has taken affect:
-+
-[source,bash]
-----
-kubectl logs -f -n deployment/
-----
-
-== Reverting proxy logging levels
-
-This procedure describes how to revert the logging level of the Kroxylicious Proxy back to its defaults.
-
-.Prerequisites
-
-* An instance of Kroxylicious deployed by the Kroxylicious Operator.
-
-.Procedure
-
-. Remove the `KROXYLICIOUS_APP_LOG_LEVEL` or `KROXYLICIOUS_ROOT_LOG_LEVEL` environment variable from the proxy's Kubernetes Deployment:
-+
-[source,bash]
-----
-kubectl set env -n deployment KROXYLICIOUS_APP_LOG_LEVEL-
-----
-+
-Kubernetes recreates the proxy pod automatically.
-. Verify that the logging level has reverted to its default:
-+
-[source,bash]
-----
-kubectl logs -f -n deployment/
-----
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-proxy-introducing-metrics.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-proxy-introducing-metrics.adoc
deleted file mode 100644
index 9cbb9cf7..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-proxy-introducing-metrics.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-// file included in the following:
-//
-// assembly-monitoring-proxy.adoc
-
-[id='proc-proxy-introducing-metrics-{context}']
-= Introducing metrics
-
-[role="_abstract"]
-If you want to introduce metrics to your Kroxylicious deployment, you can configure an insecure HTTP and Prometheus endpoint (at `/metrics`).
-
-Add the following to the `ConfigMap` resource that defines the Kroxylicious configuration:
-
-.Minimal metrics configuration
-[source,yaml]
-----
-management:
- endpoints:
- prometheus: {}
-----
-
-By default, the HTTP endpoint listens on `0.0.0.0:9190`.
-You can change the bind address and port as follows:
-
-.Example metrics configuration with bind address and port
-[source,yaml]
-----
-management:
- bindAddress: 127.0.0.1
- port: 9999
- endpoints:
- prometheus: {}
-----
-
diff --git a/docs/v0.13.0/_files/modules/monitoring/proc-proxy-setting-log-levels.adoc b/docs/v0.13.0/_files/modules/monitoring/proc-proxy-setting-log-levels.adoc
deleted file mode 100644
index 3286fd2e..00000000
--- a/docs/v0.13.0/_files/modules/monitoring/proc-proxy-setting-log-levels.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-
-// file included in the following:
-//
-// assembly-proxy-monitoring.adoc
-
-[id='proc-proxy-setting-log-levels-{context}']
-= Setting log levels
-
-[role="_abstract"]
-
-The Kroxylicious {github-releases}[binary distribution^] includes https://logging.apache.org/log4j/2.x[log4j2] as the default logging backend.
-
-When using the `bin/kroxylicious-start.sh` script from the binary distribution, you can set an environment variable to load a custom `log4j2` configuration file or change the root logging level.
-
-.Environment variable to load a custom `log4j2` file
-[source,properties]
-----
-KROXYLICIOUS_LOGGING_OPTIONS="-Dlog4j2.configurationFile=/path/to/custom/log4j2.yaml"
-----
-
-.Environment variable to change the root logging level
-[source,properties]
-----
-KROXYLICIOUS_ROOT_LOG_LEVEL="DEBUG"
-----
-
-NOTE: Setting the root log level to `DEBUG` or `TRACE` will produce very verbose logs.
diff --git a/docs/v0.13.0/_files/modules/multi-tenancy/proc-multi-tenancy.adoc b/docs/v0.13.0/_files/modules/multi-tenancy/proc-multi-tenancy.adoc
deleted file mode 100644
index 99dcb6a0..00000000
--- a/docs/v0.13.0/_files/modules/multi-tenancy/proc-multi-tenancy.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-// file included in the following:
-//
-// assembly-multi-tenancy-filter.adoc
-
-[id='proc-multi-tenancy-{context}']
-= (Preview) Setting up the Multi-tenancy filter
-
-[role="_abstract"]
-This procedure describes how to set up the Multi-tenancy filter by configuring it in Kroxylicious.
-The filter dynamically prefixes resource names to create isolation between tenants using the same Kafka cluster.
-The prefix representing a tenant is taken from the name of the virtual cluster representing the tenant.
-For example, if the virtual cluster is named `tenant-1`, the prefix is `tenant-1`.
-Each tenant must be represented by a unique virtual cluster, and virtual cluster names must be globally unique within the Kroxylicious configuration.
-This means that the same virtual cluster name cannot be used to represent different Kafka clusters.
-
-.Prerequisites
-
-* An instance of Kroxylicious.
-For information on deploying Kroxylicious, see the link:{github}[samples and examples^].
-* A config map for Kroxylicious that includes the configuration for creating virtual clusters and filters.
-* A virtual cluster definition for each tenant using the Kafka cluster.
-You need at least two virtual clusters to apply multi-tenancy.
-
-.Procedure
-
-. Configure a `MultiTenant` type filter.
-+
-[source, yaml]
-----
-filterDefinitions:
- - name: my-multi-tenant-filter
- type: MultiTenant
- config:
- prefixResourceNameSeparator: "." # <1>
-----
-<1> The separator used for the prefix.
-If a separator is not specified, `-` is the default.
-+
-NOTE: Currently, only the prefix with separator is validated.
-
-. Verify that multi-tenancy filtering has been applied.
-+
-For example, create a topic through each virtual cluster and check that the topics are prefixed with the name of the corresponding virtual cluster.
-+
-For more information, see the {github}/blob/main/kubernetes-examples/filters/multi-tenant/script.txt[example for a Kubernetes environment].
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/oauthbearer/con-oauthbearer.adoc b/docs/v0.13.0/_files/modules/oauthbearer/con-oauthbearer.adoc
deleted file mode 100644
index 24ea9f02..00000000
--- a/docs/v0.13.0/_files/modules/oauthbearer/con-oauthbearer.adoc
+++ /dev/null
@@ -1,106 +0,0 @@
-// file included in the following:
-//
-// assembly-built-in-filters.adoc
-
-[id='con-oauthbearer-{context}']
-= OAUTHBEARER validation
-
-[role="_abstract"]
-OauthBearerValidation filter enables a validation on the JWT token received from client before forwarding it to cluster.
-
-If the token is not validated, then the request is short-circuited.
-It reduces resource consumption on the cluster when a client sends too many invalid SASL requests.
-
-[a2s, format="svg"]
-....
-.----------------------------------------------------------------------------------------.
-| |
-| '---------' '---------------' '----------' |
-| | | | | | | |
-| | Client | | Kroxylicious | | Cluster | |
-| | | | | | | |
-| '---------' '---------------' '----------' |
-| | | | |
-| | Handshake request | | |
-| |==============================>| Forward handshake request | |
-| | |===============================>| |
-| | | Handshake response | |
-| | Handshake response |<===============================| |
-| |<==============================| | |
-| | | | |
-| | | | |
-| | Authenticate request | | |
-| |==============================>| | |
-| | |==+ | |
-| | | : Validate Token | |
-| | |<=+ | |
-| | | | |
-| '=======|===============================|==' | |
-| :if | [Validation fails] | : | |
-| : | | : | |
-| : | Invalid token | : | |
-| : |<==============================| : | |
-| : | | : | |
-| '=======|===============================|==' | |
-| | | | |
-| '=======|===============================|================================|==' |
-| :if | [Validation succeeds] | | : |
-| : | | Forward authenticate request | : |
-| : | |===============================>| : |
-| : | | Authenticate response | : |
-| : | |<===============================| : |
-| : | Authenticate response | | : |
-| : |<==============================| | : |
-| : | | | : |
-| '=======|===============================|================================|==' |
-| | | | |
-| | | | |
-| '---------' '---------------' '----------' |
-| | | | | | | |
-| | Client | | Kroxylicious | | Cluster | |
-| | | | | | | |
-| '---------' '---------------' '----------' |
-| |
-.----------------------------------------------------------------------------------------.
-[0,0]: {"fill":"#99d","a2s:delref":1}
-....
-
-== How to use the filter
-
-There are two steps to using the filter.
-
-1. <>
-2. Configuring the filter within Kroxylicious.
-
-=== Configuring the filter within Kroxylicious.
-
-[source, yaml]
-----
-filterDefinitions:
- - name: my-oauth-filter
- type: OauthBearerValidation
- config:
- jwksEndpointUrl: https://oauth/JWKS #<1>
- jwksEndpointRefreshMs: 3600000 #<2>
- jwksEndpointRetryBackoffMs: 100 #<3>
- jwksEndpointRetryBackoffMaxMs: 10000 #<4>
- scopeClaimName: scope #<5>
- subClaimName: sub #<6>
- authenticateBackOffMaxMs: 60000 #<7>
- authenticateCacheMaxSize: 1000 #<8>
- expectedAudience: https://first.audience, https//second.audience #<9>
- expectedIssuer: https://your-domain.auth/ #<10>
-----
-
-<1> The OAuth/OIDC provider URL from which the provider's JWKS (JSON Web Key Set) can be retrieved.
-<2> The (optional) value in milliseconds for the broker to wait between refreshing its JWKS (JSON Web Key Set) cache that contains the keys to verify the signature of the JWT.
-<3> The (optional) value in milliseconds for the initial wait between JWKS (JSON Web Key Set) retrieval attempts from the external authentication provider.
-<4> The (optional) value in milliseconds for the maximum wait between attempts to retrieve the JWKS (JSON Web Key Set) from the external authentication provider.
-<5> This (optional) setting can provide a different name to use for the scope included in the JWT payload's claims.
-<6> This (optional) setting can provide a different name to use for the subject included in the JWT payload's claims.
-<7> The (optional) maximum value in milliseconds to limit the client sending authenticate request. Setting 0 will never limit the client. Otherwise, an exponential delay is added to each authenticate request until the authenticateBackOffMaxMs has been reached.
-<8> The (optional) maximum number of failed tokens kept in cache.
-<9> The (optional) comma-delimited setting for the broker to use to verify that the JWT was issued for one of the expected audiences.
-<10> The (optional) setting for the broker to use to verify that the JWT was created by the expected issuer.
-
-Note: OauthBearer config follows https://kafka.apache.org/documentation/#security_ssl[kafka's properties]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-key-creation.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-key-creation.adoc
deleted file mode 100644
index 5bbed78e..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-key-creation.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-// file included in the following:
-//
-// assembly-aws-kms.adoc
-
-[id='con-aws-kms-key-creation-{context}']
-= Creating AWS KMS keys
-
-As the administrator, use either the AWS Console or CLI to
-{aws}/kms/latest/developerguide/create-keys.html#create-symmetric-cmk[create] a *Symmetric key* with *Encrypt and decrypt*
-usage.
-Multi-region keys are supported.
-
-NOTE: It is not possible to make use of keys from other AWS accounts. For more information on this limitation, see the issue for link:https://github.com/kroxylicious/kroxylicious/issues/1217[AWS KMS serde improvements^].
-
-Give the key an alias as described in xref:con-aws-kms-setup-{context}[].
-
-If using the CLI, this can be done with commands like this:
-
-[source,shell]
-----
-KEY_ALIAS="KEK_"
-KEY_ID=$(aws kms create-key | jq -r '.KeyMetadata.KeyId')
-# the create key command will produce JSON output including the KeyId
-aws kms create-alias --alias-name alias/${KEY_ALIAS} --target-key-id ${KEY_ID}
-----
-
-Once the key is created, it is recommended to use a key rotation policy.
-
-[source,shell]
-----
-aws kms enable-key-rotation --key-id ${KEY_ID} --rotation-period-in-days 180
-----
-
-
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-plugin-configuration.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-plugin-configuration.adoc
deleted file mode 100644
index fb9bac76..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-plugin-configuration.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-// file included in the following:
-//
-// assembly-configuring-record-encryption-filter
-
-[id='con-aws-kms-plugin-configuration-{context}']
-= AWS KMS plugin configuration
-
-For AWS KMS the configuration for authenticating with AWS KMS services looks like this:
-
-include::con-aws-kms-service-config-identity-long-term.adoc[leveloffset=+1]
-
-ifdef::include-aws-kms-service-config-identity-ec2-metadata[]
-
-Alternatively, the configuration for authenticating with EC2 metadata looks like this:
-
-include::con-aws-kms-service-config-identity-ec2-metadata.adoc[leveloffset=+1]
-endif::[]
-
-include::../../../snippets/snip-tls-client-keystore.adoc[]
-
-include::../../../snippets/snip-tls-client-truststore.adoc[]
-
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-service-config-identity-ec2-metadata.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-service-config-identity-ec2-metadata.adoc
deleted file mode 100644
index dade8c81..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-service-config-identity-ec2-metadata.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-// file included in the following:
-//
-// con-aws-kms-plugin-configuration.adoc
-
-
-.Configuration for authenticating with EC2 metadata
-[source, yaml]
-----
-kms: AwsKmsService # <1>
-kmsConfig:
- endpointUrl: https://kms..amazonaws.com # <2>
- ec2MetadataCredentials:
- iamRole: # <3>
- metadataEndpoint: # <4>
- credentialLifetimeFactor: 0.8 # <5>
- region: # <6>
-----
-<1> Specifies the name of the KMS provider. Use `AwsKmsService`.
-<2> AWS KMS endpoint URL, which must include the `https://` scheme.
-<3> Name of the IAM role associated with the EC2 instance(s) hosting Kroxylicious.
-<4> (Optional) Metadata endpoint used to obtain EC2 metadata.
-Defaults to `\http://169.254.169.254/`.
-If using IPv6, use `http://[fd00:ec2::254]` instead.
-<5> (Optional) Factor used to determine when to refresh a credential before it expires.
-Defaults to `0.8`, which means the credential is refreshed once it reaches 80% of its lifetime.
-<6> The AWS region identifier, such as `us-east-1`, specifying where your KMS resources are located.
-This must match the region of the KMS endpoint you're using.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-service-config-identity-long-term.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-service-config-identity-long-term.adoc
deleted file mode 100644
index 5d5cd434..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-service-config-identity-long-term.adoc
+++ /dev/null
@@ -1,27 +0,0 @@
-// file included in the following:
-//
-// con-aws-kms-plugin-configuration.adoc
-
-
-.Configuration for authenticating with a long-term IAM identity
-[source, yaml]
-----
-kms: AwsKmsService # <1>
-kmsConfig:
- endpointUrl: https://kms..amazonaws.com # <2>
- tls: # <3>
- # ...
- longTermCredentials:
- accessKeyId:
- passwordFile: /opt/aws/accessKey # <4>
- secretAccessKey:
- passwordFile: /opt/aws/secretKey # <5>
- region: # <6>
-----
-<1> Specifies the name of the KMS provider. Use `AwsKmsService`.
-<2> AWS KMS endpoint URL, which must include the `https://` scheme.
-<3> (Optional) TLS trust configuration.
-<4> File containing the AWS access key ID.
-<5> File containing the AWS secret access key.
-<6> The AWS region identifier, such as `us-east-1`, specifying where your KMS resources are located.
-This must match the region of the KMS endpoint you're using.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-setup.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-setup.adoc
deleted file mode 100644
index f22da379..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/con-aws-kms-setup.adoc
+++ /dev/null
@@ -1,88 +0,0 @@
-// file included in the following:
-//
-// assembly-aws-kms.adoc
-
-[id='con-aws-kms-setup-{context}']
-= Establish an aliasing convention for keys within AWS KMS
-
-The filter references KEKs within AWS via an {aws}/kms/latest/developerguide/alias-about.html[AWS key alias].
-
-Establish a naming convention for key aliases to keep the filter’s keys separate from those used by other systems.
-Here, we use a prefix of KEK_ for filter aliases.
-Adjust the instructions if a different naming convention is used.
-
-== Role of the administrator
-
-To use the filter, an administrator or an administrative process must create the encryption keys within AWS KMS, which
-are used by the xref:con-topic-encryption-overview-{context}[envelope encryption] process.
-
-The organization deploying the Record Encryption filter is responsible for managing this administrator or process.
-
-The administrator must have permissions to create keys in AWS KMS.
-As a starting point, the built-in AWS policy `AWSKeyManagementServicePowerUser` confers sufficient key management privileges.
-
-To get started, use the following commands to set up an administrator with permissions suitable for managing encryption keys in KMS through an AWS Cloud Shell.
-This example illustrates using the user name `kroxylicious-admin`, but you can choose a different name if preferred.
-Adjust the instructions accordingly if you use a different user name.
-
-[source,shell]
-----
-ADMIN=kroxylicious-admin
-INITIAL_PASSWORD=$(aws secretsmanager get-random-password --output text)
-CONSOLE_URL=https://$(aws sts get-caller-identity --query Account --output text).signin.aws.amazon.com/console
-aws iam create-user --user-name ${ADMIN}
-aws iam attach-user-policy --user-name ${ADMIN} --policy-arn arn:aws:iam::aws:policy/AWSKeyManagementServicePowerUser
-aws iam attach-user-policy --user-name ${ADMIN} --policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword
-aws iam attach-user-policy --user-name ${ADMIN} --policy-arn arn:aws:iam::aws:policy/AWSCloudShellFullAccess
-aws iam create-login-profile --user-name ${ADMIN} --password "${INITIAL_PASSWORD}" --password-reset-required
-echo Now log in at ${CONSOLE_URL} with user name ${ADMIN} password "${INITIAL_PASSWORD}" and change the password.
-----
-
-[id='con-aws-kms-setup-policy-{context}']
-== Create an alias-based policy for KEK aliases
-
-Create an alias-based policy granting permissions to use keys aliased by the established alias naming convention.
-
-[source,shell]
-----
-AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
-cat > /tmp/policy << EOF
-{
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "AliasBasedIAMPolicy",
- "Effect": "Allow",
- "Action": [
- "kms:Encrypt",
- "kms:Decrypt",
- "kms:GenerateDataKey*",
- "kms:DescribeKey"
- ],
- "Resource": [
- "arn:aws:kms:*:${AWS_ACCOUNT_ID}:key/*"
- ],
- "Condition": {
- "ForAnyValue:StringLike": {
- "kms:ResourceAliases": "alias/KEK_*"
- }
- }
- }
- ]
-}
-EOF
-aws iam create-policy --policy-name KroxyliciousRecordEncryption --policy-document file:///tmp/policy
-----
-
-== Establish an authentication mechanism for the filter
-
-The filter must authenticate to AWS in order to perform envelope encryption operations, such as generating and decrypting DEKs.
-
-include::proc-aws-kms-setup-application-identity-long-term.adoc[leveloffset=+1]
-ifdef::include-aws-kms-service-config-identity-ec2-metadata[]
-include::proc-aws-kms-setup-application-identity-ec2-metadata.adoc[leveloffset=+1]
-endif::[]
-
-
-
-
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/proc-aws-kms-setup-application-identity-ec2-metadata.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/proc-aws-kms-setup-application-identity-ec2-metadata.adoc
deleted file mode 100644
index 7bd198bb..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/proc-aws-kms-setup-application-identity-ec2-metadata.adoc
+++ /dev/null
@@ -1,88 +0,0 @@
-// file included in the following:
-//
-// con-aws-kms-setup.adoc
-
-[id='proc-aws-kms-setup-application-ec2-metadata-{context}']
-
-= Authenticating using AWS EC2 metadata
-
-[role="_abstract"]
-This procedure describes how to use AWS EC2 metadata for the Record Encryption filter to authenticate to AWS KMS.
-The process involves creating a trust policy, creating an IAM role, and attaching an alias-based policy that grants permissions to perform KMS operations on specific KEKs.
-
-The filter authenticates using the temporary credentials retrieved from {aws}/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials[EC2 instance metadata].
-
-.Prerequisites
-
-* Access to the AWS CLI with sufficient permissions to create and manage IAM users.
-* xref:con-aws-kms-setup-policy-{context}[An alias-based policy created for the Record Encryption filter].
-
-.Procedure
-
-. Create a trust policy:
-+
-[source,shell]
-----
-cat > trustpolicy << EOF
-{
- "Version": "2012-10-17",
- "Statement": [
- {
- "Effect": "Allow",
- "Action": [
- "sts:AssumeRole"
- ],
- "Principal": {
- "Service": [
- "ec2.amazonaws.com"
- ]
- }
- }
- ]
-}
-EOF
-----
-+
-The trust policy specifies that the EC2 instance can assume the role, enabling it to retrieve and use temporary credentials for authentication.
-
-. Create the IAM role using the trust policy:
-+
-[source,shell]
-----
-aws iam create-role --role-name KroxyliciousInstance --assume-role-policy-document file://trustpolicy
-----
-+
-This example uses `KroxyliciousInstance` as the role name, but you can substitute a different name if necessary.
-
-. Attach the alias-based policy to the role:
-+
-[source,shell]
-----
-AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
-aws iam attach-role-policy --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/KroxyliciousRecordEncryption --role-name KroxyliciousInstance
-----
-+
-This step grants the role permission to perform KMS operations on KEKs that use the alias naming convention defined in the `KroxyliciousRecordEncryption` policy.
-
-. Verify that the policy has been successfully attached:
-+
-[source,shell]
-----
-aws iam list-attached-role-policies --role-name KroxyliciousInstance
-----
-
-. Associate the role with the EC2 instance:
-+
-[source,shell]
-----
-aws ec2 associate-iam-instance-profile --instance-id --iam-instance-profile Name="KroxyliciousInstance"
-----
-+
-Replace `` with the instance ID of each AWS EC2 instance hosting a Kroxylicious instance.
-
-. Verify that the role has been associated with the EC2 instance:
-+
-[source,shell]
-----
-aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=
-----
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/proc-aws-kms-setup-application-identity-long-term.adoc b/docs/v0.13.0/_files/modules/record-encryption/aws-kms/proc-aws-kms-setup-application-identity-long-term.adoc
deleted file mode 100644
index fc070511..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/aws-kms/proc-aws-kms-setup-application-identity-long-term.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-// file included in the following:
-//
-// con-aws-kms-setup.adoc
-
-[id='proc-aws-kms-setup-application-identity-long-term-{context}']
-
-= Authenticating using long-term IAM identity
-
-[role="_abstract"]
-This procedure describes how to create a long-term IAM identity for the Record Encryption filter to authenticate to AWS KMS.
-The process involves creating an IAM user and access key, and attaching an alias-based policy that grants permissions to perform KMS operations on specific KEKs.
-
-NOTE: Do not enable console access for this user.
-The filter requires only API access, and console access would unnecessarily increase the security risk.
-
-.Prerequisites
-
-* Access to the AWS CLI with sufficient permissions to create and manage IAM users.
-* xref:con-aws-kms-setup-policy-{context}[An alias-based policy created for the Record Encryption filter].
-
-.Procedure
-
-. Create the IAM user and access key:
-+
-[source,shell]
-----
-aws iam create-user --user-name kroxylicious
-aws iam create-access-key --user-name kroxylicious
-----
-+
-This example uses `kroxylicious` as the user name, but you can substitute a different name if necessary.
-
-. Attach the alias-based policy to the IAM identity:
-+
-[source,shell]
-----
-AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
-aws iam attach-user-policy --user-name kroxylicious --policy-arn "arn:aws:iam::${AWS_ACCOUNT_ID}:policy/KroxyliciousRecordEncryption"
-----
-+
-This step grants the user permission to perform KMS operations on KEKs that use the alias naming convention defined in the `KroxyliciousRecordEncryption` policy.
-
-. Verify that the policy has been successfully attached:
-+
-[source,shell]
-----
-aws iam list-attached-user-policies --user-name kroxylicious
-----
-
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-about-record-encryption-guide.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-about-record-encryption-guide.adoc
deleted file mode 100644
index 69c6375f..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-about-record-encryption-guide.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
-
-[discrete]
-= About this guide
-
-This guide covers using the *Kroxylicious Record Encryption Filter* to provide encryption-at-rest for Apache Kafka.
-Refer to other Kroxylicious guides for information on running the proxy or for advanced topics such as plugin development.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-example-kafkaprotocolfilter-resource.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-example-kafkaprotocolfilter-resource.adoc
deleted file mode 100644
index afa87afa..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-example-kafkaprotocolfilter-resource.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-// file included in the following:
-//
-// assembly-configuring-record-encryption-filter
-
-[id='con-example-kafkaprotocolfilter-resource-{context}']
-= Example `KafkaProtocolFilter` resource
-
-If your instance of Kroxylicious runs on Kubernetes, you must use a `KafkaProcotolFilter` resource to contain the filter configuration.
-
-Here's a complete example of a `KafkaProtocolFilter` resource configured for record encryption with Vault KMS:
-
-.Example `KafkaProtocolFilter` resource
-[source,yaml]
-----
-kind: KafkaProtocolFilter
-metadata:
- name: my-encryption-filter
-spec:
- type: RecordEncryption
- configTemplate:
- kms: VaultKmsService
- kmsConfig:
- vaultTransitEngineUrl: # ...
- tls: # ...
- vaultToken:
- passwordFile: ${secret:encryption-filter:vault-token}
- selector: TemplateKekSelector
- selectorConfig:
- template: "KEK_$(topicName)"
- unresolvedKeyPolicy: PASSTHROUGH_UNENCRYPTED
- experimental:
- encryptionDekRefreshAfterWriteSeconds: 3600
- encryptionDekExpireAfterWriteSeconds: 7200
- maxEncryptionsPerDek: 5000000
-----
-
-Refer to the {OperatorGuide} for more information about configuration on Kubernetes.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-example-proxy-config.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-example-proxy-config.adoc
deleted file mode 100644
index 4f679f2c..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-example-proxy-config.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-// file included in the following:
-//
-// assembly-configuring-record-encryption-filter
-
-[id='con-example-proxy-config-{context}']
-= Example proxy configuration file
-
-If your instance of the Kroxylicious proxy runs directly on an operating system, provide the filter configuration in the `filterDefinitions` list of your proxy configuration.
-Here's a complete example of a `filterDefinitions` entry configured for record encryption with Vault KMS:
-
-.Example `filterDefinitions` configuration
-[source,yaml]
-----
-filterDefinitions:
- - name: my-encryption-filter
- type: RecordEncryption
- config:
- kms: VaultKmsService
- kmsConfig:
- vaultTransitEngineUrl: # ...
- tls: # ...
- vaultToken:
- passwordFile: /opt/vault/token
- selector: TemplateKekSelector
- selectorConfig:
- template: "KEK_$(topicName)"
- unresolvedKeyPolicy: PASSTHROUGH_UNENCRYPTED
- experimental:
- encryptionDekRefreshAfterWriteSeconds: 3600
- encryptionDekExpireAfterWriteSeconds: 7200
- maxEncryptionsPerDek: 5000000
-----
-
-Refer to the {ProxyGuide} for more information about configuring the proxy.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-lost-kek.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-lost-kek.adoc
deleted file mode 100644
index e4703376..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-lost-kek.adoc
+++ /dev/null
@@ -1,93 +0,0 @@
-// file included in the following:
-//
-// assemblies/assembly-operations-record-encryption-filter.adoc
-
-[id='con-lost-kek-{context}']
-= Dealing with a lost KEK
-
-This section discusses what to do if you lose a KEK that is still required to decrypt records.
-For the purposes of this section, 'lost' means that the KMS is available to the filter but is not able to perform encryption operations using the KEK.
-
-WARNING: Deleting KEKs from the KMS is not recommended.
-Figuring out which KEKs are no longer used by any records in a Kafka cluster is non-trivial.
-Any remaining records encrypted using a deleted KEK will become *unrecoverable*.
-In addition, consumers will be unable to read beyond those unrecoverable records without specific intervention, meaning business processing will stop.
-We recommend never deleting KEKs. As such, this procedure is provided for emergency use only.
-
-When consumers try to fetch an undecryptable record they will receive an error response from the proxy.
-The precise details of the failure will vary depending on the Kafka Client library being used by the application.
-The error message may look like one of these:
-
-* `Unexpected error code 91 while fetching at offset n from topic-partition -` (Apache Kafka client).
-* `Fetch from broker 0 failed at offset n (leader epoch 0): Broker: Request illegally referred to resource that does not exist` (`Librdkafka` based client)
-
-Other clients may refer to the error code 91.
-
-Error code 91 (Resource not found) is the error number used by the Record Encryption filter to indicate that the required encryption key (KEK) is not available on the KMS.
-
-Once you have identified the issue on the client side, confirm that you indeed have a lost KEK situation, by checking the proxy logs.
-There will be messages like this:
-
-[source]
-----
-Failed to decrypt record in topic-partition - owing to key not found condition.
-This will be reported to the client as a RESOURCE_NOT_FOUND(91).
-Client may see a message like 'Unexpected error code 91 while fetching at offset' (java) or or 'Request illegally referred to resource that does not exist' (librdkafka).
-Cause message: key 'd691a642-d8b4-4445-b668-d390df7000bb' is not found (AWS error: ErrorResponse{type='KMSInvalidStateException', message='arn:aws:kms:us-east-1:000000000000:key/d691a642-d8b4-4445-b668-d390df7000bb is pending deletion.'}).
-Raise log level to DEBUG to see the stack.
-----
-
-In this situation, there are three recovery strategies that may be used.
-These are discussed, in order of preference, in the next sections.
-
-== Unschedule key's deletion
-
-Some KMS providers don't actually immediately delete encryption keys.
-Instead, a key is _scheduled_ for deletion at some time in the future.
-When the key is in this state, the key behaves as if it were gone already.
-
-This gives you a grace period where you can change your mind.
-
-Use the Console of the KMS to determine if the missing key is scheduled for deletion.
-If this is the case, use the features of the KMS to undelete the key.
-
-Refer to documentation of the KMS for more details.
-
-After the key has been undeleted, restart the proxy instances.
-Consuming applications should resume as normal.
-
-== Recover the key from backup
-
-If you have a backup of the keys in your KMS, you will be able to recover the key from the backup.
-
-The precise details of how to do this will depend on which KMS you use.
-Refer to documentation of the KMS for more details.
-
-After the KEK has been recovered from backup and restored to the KMS, restart the proxy instances.
-Applications should begin consuming again as normal.
-
-NOTE: When restoring the key to your KMS, it is important to restore the associated metadata, such as its identifiers, in addition to the key material itself. The Record Encryption filter stores references to the key identifier in the cipher text record. Restoring the key material alone is not sufficient.
-
-== Delete the records encrypted by the lost KEK or advance the consumer groups past them
-
-The final two options are:
-
-* delete the records encrypted with the lost KEK from Kafka, or
-* advance the consumer group offsets used by your applications so that they skip the records that can't be decrypted.
-
-The first challenge is to identify the offsets in the topics after which use of the deleted KEK has ceased.
-Proxy instances won't necessarily respond to a key rotation at the same moment.
-This means there will be periods where some proxy instances will be using older encryption keys whilst others use newer ones.
-The overall effect of this is that there may not be a single point in the transaction log where encryption switches from one KEK to the next.
-
-You can use a tool such as Apache Kafka's `kafka-console-consumer.sh` with binary search approach to discover the oldest offset that is followed exclusively by records that decrypt successfully.
-Repeat this process for every partition for every affected topic.
-You may be able to use domain specific knowledge to help you narrow the search space.
-
-Once you have identified the new starting offset for every affected topic partition, you can use either
-`kafka-delete-records.sh` to delete the undecryptable records or use `kafka-consumer-groups` to reset the consumer group
-offsets.
-
-`kafka-delete-records.sh` only allows deleting records from the tail of the log. This means any readable records prior to the undecryptable ones will also be deleted. However, deleting records is an action that need only be done once. Whereas resetting consumer offsets needs to be done for each consumer or consumer group which ever needs to read beyond the undecryptable records.
-
-After this has been done, applications should be able to begin consuming again, albeit without the lost data.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-metrics.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-metrics.adoc
deleted file mode 100644
index 6f33e5cd..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-metrics.adoc
+++ /dev/null
@@ -1,73 +0,0 @@
-// file included in the following:
-//
-// record-encryption-guide/assembly-monitoring-record-encryption-filter.adoc
-
-[id='con-monitoring-record-encryption-filter-{context}']
-= Record Encryption filter metrics
-
-[role="_abstract"]
-
-The filter emits metrics that provide insights into its interactions with the configured KMS.
-They indicate the load the filter places on the KMS infrastructure and how often its interactions with the KMS fail.
-
-The filter emits metrics that count the number of records that are being encrypted.
-This can help you verify that the filter is configured properly and encrypting specific topics as intended.
-
-These metrics are made available automatically once metrics are enabled in the proxy.
-
-== KMS metrics
-
-KMS metrics track and count the following types of interactions:
-
-* Generating DEK pairs
-* Decrypting EDEKs
-* Resolving KEK aliases
-
-.KMS metrics
-|===
-|Metric Name |Type |Labels|Description
-
-|`kroxylicious_kms_operation_attempt_total`
-|Counter
-|`operation`
-|Count of the number of KMS operations attempted.
-
-|`kroxylicious_kms_operation_outcome_total`
-|Counter
-|`operation`, `outcome`
-|Count of the number of KMS operations grouped by outcome.
-|===
-
-.Labels used on the KMS metrics
-|===
-|Label|Domain|Description
-
-|`operation`
-|`generate_dek_pair`, `decrypt_edek`, `resolve_alias`
-|Type of operation performed.
-
-|`outcome`
-|`SUCCESS`, `EXCEPTION`, `NOT_FOUND`
-|Result of the operation.
-|===
-
-== Encryption accounting metrics
-
-Encryption accounting metrics count the number of records sent to topics that are encrypted and the number of records sent to topics that are not configured for encryption.
-These metrics are discriminated by topic name.
-Use these metrics to confirm you configuration is having the effect you desired.
-
-.Encryption accounting metrics
-|===
-|Metric Name |Type |Labels|Description
-
-|`kroxylicious_filter_record_encryption_encrypted_records`
-|Counter
-|`topic_name`
-|Count of the number of records encrypted by the filter.
-
-|`kroxylicious_filter_record_encryption_plain_records`
-|Counter
-|`topic_name`
-|Count of the number of records _not_ encrypted by the filter.
-|===
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-record-encryption-filter-config.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-record-encryption-filter-config.adoc
deleted file mode 100644
index 1e46ecbc..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-record-encryption-filter-config.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-// file included in the following:
-//
-// assembly-configuring-record-encryption-filter
-
-[id='con-record-encryption-filter-config-{context}']
-= Filter configuration
-
-[role="_abstract"]
-This procedure describes how to configure the Record Encryption filter.
-Provide the filter configuration and the Key Encryption Key (KEK) selector to use.
-The KEK selector maps topic name to key names.
-The filter looks up the resulting key name in the KMS.
-
-.Prerequisites
-
-* An instance of Kroxylicious.
-For information on deploying Kroxylicious, see the
-{ProxyGuide} or {OperatorGuide}.
-* A KMS is installed and set up for the filter with KEKs to encrypt records set up for topics.
-
-.Procedure
-
-. Configure a `RecordEncryption` type filter.
-+
-.Example Record Encryption filter configuration
-[source,yaml]
-----
-kms: # <1>
-kmsConfig:
- # <2>
- # ...
-selector: # <3>
-selectorConfig:
- template: "KEK_$(topicName)" # <4>
-unresolvedKeyPolicy: PASSTHROUGH_UNENCRYPTED # <5>
-experimental:
- encryptionDekRefreshAfterWriteSeconds: 3600 # <6>
- encryptionDekExpireAfterWriteSeconds: 7200 # <7>
- maxEncryptionsPerDek: 5000000 # <8>
-----
-<1> The KMS service name.
-<2> Configuration specific to the KMS provider.
-<3> The Key Encryption Key (KEK) selector to use. The `$(topicName)` is a literal understood by the proxy.
-For example, if using the `TemplateKekSelector` with the template `KEK_$(topicName)`, create a key for every topic that
-is to be encrypted with the key name matching the topic name, prefixed by the string `KEK_`.
-<4> The template for deriving the KEK, based on a specific topic name.
-<5> Optional policy governing the behaviour when the KMS does not contain a key. The default is `PASSTHROUGH_UNENCRYPTED` which
-causes the record to be forwarded, unencrypted, to the target cluster. Users can alternatively specify `REJECT` which
-will cause the entire produce request to be rejected. This is a safer alternative if you know that all traffic sent
-to the Virtual Cluster should be encrypted because unencrypted data will never be forwarded.
-<6> How long after creation of a DEK before it becomes eligible for rotation. On the **next** encryption request, the cache will asynchronously create a new DEK. Encryption requests will continue to use the old DEK until the new DEK is ready.
-<7> How long after creation of a DEK until it is removed from the cache. This setting puts an upper bound on how long a DEK can remain cached.
-<8> The maximum number of records any DEK should be used to encrypt. After this limit is hit, that DEK will be destroyed and a new one created.
-+
-`encryptionDekRefreshAfterWriteSeconds` and `encryptionDekExpireAfterWriteSeconds` properties govern the _originator usage period_ of the DEK, which is the amount of time the DEK remains valid for encrypting records. Shortening this period helps limit the impact if the DEK key material is leaked. However, shorter periods increase the number of KMS API calls, which might affect produce and consume latency and raise KMS provider costs.
-+
-`maxEncryptionsPerDek` helps prevent key exhaustion by placing an upper limit of the amount of times that a DEK may be used to encrypt records.
-
-. Verify that the encryption has been applied to the specified topics by producing messages through the proxy and then consuming directly and indirectly from the Kafka cluster.
-
-NOTE: If the filter is unable to find the key in the KMS, the filter passes through the records belonging to that topic in the produce request without encrypting them.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/con-record-encryption-overview.adoc b/docs/v0.13.0/_files/modules/record-encryption/con-record-encryption-overview.adoc
deleted file mode 100644
index 38c6aa50..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/con-record-encryption-overview.adoc
+++ /dev/null
@@ -1,103 +0,0 @@
-// file included in the following:
-//
-// record-encryption-guide/index.adoc
-
-[id='con-topic-encryption-overview-{context}']
-= How encryption works
-
-[role="_abstract"]
-The Record Encryption filter uses envelope encryption to encrypt records with symmetric encryption keys.
-The filter encrypts records from produce requests and decrypts records from fetch responses.
-
-Envelope encryption::
-Envelope encryption is an industry-standard technique suited for encrypting large volumes of data in an efficient manner.
-Data is encrypted with a Data Encryption Key (DEK).
-The DEK is encrypted using a Key Encryption Key (KEK).
-The KEK is stored securely in a Key Management System (KMS).
-Symmetric encryption keys::
-AES(GCM) 256 bit encryption symmetric encryption keys are used to encrypt and decrypt record data.
-
-The process is as follows:
-
-. The filter intercepts produce requests from producing applications and transforms them by encrypting the records.
-. The produce request is forwarded to the broker.
-. The filter intercepts fetch responses from the broker and transforms them by decrypting the records.
-. The fetch response is forwarded to the consuming application.
-
-The filter encrypts the record value only.
-Record keys, headers, and timestamps are not encrypted.
-
-The entire process is transparent from the point of view of Kafka clients and Kafka brokers.
-Neither are aware that the records are being encrypted, nor do they have any access to the encryption keys or have any influence on the ciphering process to secure the records.
-
-== How the filter encrypts records
-The filter encrypts records from produce requests as follows:
-
-. Filter selects a KEK to apply.
-. Requests the KMS to generate a DEK for the KEK.
-. Uses an encrypted DEK (DEK encrypted with the KEK) to encrypt the record.
-. Replaces the original record with a ciphertext record (encrypted record, encrypted DEK, and metadata).
-
-The filter uses a DEK reuse strategy.
-Encrypted records are sent to the same topic using the same DEK until a time-out or an encryption limit is reached.
-
-== How the filter decrypts records
-The filter decrypts records from fetch responses as follows:
-
-. Filter receives a cipher record from the Kafka broker.
-. Reverses the process that constructed the cipher record.
-. Uses KMS to decrypt the DEK.
-. Uses the decrypted DEK to decrypt the encrypted record.
-. Replaces the cipher record with a decrypted record.
-
-The filter uses an LRU (least recently used) strategy for caching decrypted DEKs.
-Decrypted DEKs are kept in memory to reduce interactions with the KMS.
-
-== How the filter uses the KMS
-To support the filter, the KMS provides the following:
-
-* A secure repository for storing Key Encryption Keys (KEKs)
-* A service for generating and decrypting Data Encryption Keys (DEKs)
-
-KEKs stay within the KMS.
-The KMS generates a DEK (which is securely generated random data) for a given KEK, then returns the DEK and an encrypted DEK.
-The encrypted DEK has the same data but encrypted with the KEK.
-The KMS doesn't store encrypted DEKs; they are stored as part of the cipher record in the broker.
-
-WARNING: The KMS must be available during runtime.
-If the KMS is unavailable, the filter will not be able to obtain new encrypted DEKs on the produce path or decrypt encrypted DEKs on the consume path. The filter will continue to use previously obtained DEKs, but eventually, production and consumption will become impossible.
-It is recommended to use the KMS in a high availability (HA) configuration.
-
-== Practicing key rotation
-
-Key rotation involves periodically replacing cryptographic keys with new ones and is considered a best practice in cryptography.
-
-The filter allows the rotation of Key Encryption Keys (KEKs) within the Key Management System (KMS).
-When a KEK is rotated, the new key material is eventually used for newly produced records. Existing records, encrypted with older KEK versions, remain decryptable as long as the previous KEK versions are still available in the KMS.
-
-IMPORTANT: If your encrypted topic is receiving regular traffic, the Data Encryption Key (DEK) will be refreshed as new records flow through. However, if messages are infrequent, the DEK might be used for up to 2 hours (by default) after its creation.
-
-When the KEK is rotated in the external KMS, it will take up to 1 hour (by default) before all records produced by the filter
-contain a DEK encrypted with the new key material. This is because existing encrypted DEKs are used for a configurable
-amount of time after creation, the Filter caches the encrypted DEK, one hour after creation they are eligible to be refreshed.
-
-If you need to rotate key material immediately, execute a rolling restart of your cluster of Kroxylicious instances.
-
-WARNING: If an old KEK version is removed from the KMS, records encrypted with that key will become unreadable, causing fetch operations to fail.
-In such cases, the consumer offset must be advanced beyond those records.
-
-== What part of a record is encrypted?
-
-The record encryption filter encrypts only the values of records, leaving record keys, headers, and timestamps untouched.
-Null record values, which might represent deletions in compacted topics, are transmitted to the broker unencrypted.
-This approach ensures that compacted topics function correctly.
-
-== Unencrypted topics
-
-You may configure the system so that some topics are encrypted and others are not.
-This supports scenarios where topics with confidential information are encrypted and Kafka topics with non-sensitive information can be left unencrypted.
-
-[role="_additional-resources"]
-.Additional resources
-
-* For more information on envelope encryption, see the link:https://www.nist.gov/publications/recommendation-key-management-part-1-general-1[NIST Recommendation for Key Management].
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-key-creation.adoc b/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-key-creation.adoc
deleted file mode 100644
index dda5f2e1..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-key-creation.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-// file included in the following:
-//
-// assembly-fortanix-dsm.adoc
-
-[id='con-fortanix-dsm-key-creation-{context}']
-= Creating Fortanix DSM keys
-
-As the administrator, create AES-256 symmetric keys following your key naming convention and belonging to the required group.
-When creating keys specify the key operations as `ENCRYPT,DECRYPT,APPMANAGEABLE`.
-These are the minimal permissions required for record encryption to function.
-
-Identify the ID of the group to contain the keys:
-
-[source, shell]
-----
-GROUP_ID=$(sdkms-cli --api-endpoint https://.smartkey.io list-groups | grep topic-keks | awk '{print $1}')
-----
-
-For example, here we extract the ID of the group named `topic-keks`.
-
-Create a key and associate it with the group:
-
-[source, shell]
-----
-KEY_NAME="KEK_"
-sdkms-cli --api-endpoint https://.smartkey.io create-key --obj-type AES --key-size 256 --group-id ${GROUP_ID} --name ${KEY_NAME} --key-ops ENCRYPT,DECRYPT,APPMANAGEABLE
-----
-
-TIP: It is recommended to use a key rotation policy.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-plugin-configuration.adoc b/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-plugin-configuration.adoc
deleted file mode 100644
index 8d5ecf0f..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-plugin-configuration.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-// file included in the following:
-//
-// assembly-configuring-record-encryption-filter
-
-[id='con-fortanix-dsm-plugin-configuration-{context}']
-= Fortanix DSM plugin configuration
-
-For Fortanix DSM, the KMS configuration looks like this. Use the API key and Fortanix DSM Cluster URL values from the
-KMS setup.
-
-[source, yaml]
-----
-kms: FortanixDsmKmsService # <1>
-kmsConfig:
- endpointUrl: # <2>
- apiKeySessionProvider:
- apiKey:
- passwordFile: /opt/fortanix-dsm/api-key # <3>
-----
-<1> Specifies the name of the KMS provider. Use `FortanixDsmKmsService`.
-<2> xref:con-fortanix-dsm-setup-{context}[Fortanix DSM Cluster URL] including the protocol part, such as `https:` or `http:`.
-<3> File containing the API key.
diff --git a/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-setup.adoc b/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-setup.adoc
deleted file mode 100644
index 23232a05..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/fortanix-dsm/con-fortanix-dsm-setup.adoc
+++ /dev/null
@@ -1,65 +0,0 @@
-// file included in the following:
-//
-// assembly-hashicorp-fortanix-dsm.adoc
-
-[id='con-fortanix-dsm-setup-{context}']
-= Integrate with Fortanix DSM
-
-The filter integrates with the {fortanix-dsm}[Fortanix Data Security Manager (DSM)].
-Both Fortanix DSM software-as-a service (SaaS) or an on-premise installation are supported.
-
-These instructions assume that you are using the
-link:{fortanix-support}/docs/clients-command-line-interface-cli-for-fortanix-data-security-manager[Fortanix DSM CLI],
-but you can use the Fortanix DSM user interface if preferred.
-
-NOTE: The Fortanix KMS plugin for Record Encryption doesn't yet support keys in the
-https://support.fortanix.com/docs/users-guide-key-undo-policy#50-deactivate-and-compromise-key-with-key-undo-policy[Deactivated state].
-For more information, see the {github-issues}/1767[related issue^].
-
-== Fortanix DSM Cluster URL
-
-The Record Encryption filter requires the URL of the Fortanix DSM cluster.
-
-If you are using SaaS, the URL looks like https://smartkey.io/[`https://.smartkey.io`] where `region` is an identifier such as `amer`.
-For more information, see the link: {fortanix-support}/docs/configure-api-client[Fortanix documentation].
-
-If using an on-premises instance, talk to the group responsible for it within your organization to find out
-the URL you should use.
-
-== Establish a naming convention for keys within Fortanix DSM
-
-Establish a naming convention for keys to keep the filter’s keys separate from those used by other systems.
-Here, we use a prefix of `KEK_` for filter key name.
-
-Choose the Fortanix DSM groups to keep the keys. Here, we assume a group name of `topic-keks`.
-
-Adjust the instructions if a different naming convention is used.
-
-== Role of the administrator
-
-To use the filter, an administrator or an administrative process must create the encryption keys within Fortanix DSM,
-which are used by the xref:con-topic-encryption-overview-{context}[envelope encryption] process.
-
-The organization deploying the Record Encryption filter is responsible for managing this administrator or process.
-
-The administrator must have permissions to create keys with Fortanix DSM.
-
-== Establish an application identity for the filter
-
-The filter must authenticate to Fortanix DSM in order to perform the encryption and decryption operations.
-
-Create a Fortanix DSM App with sufficient permissions for the filter:
-
-[source,shell]
-----
-sdkms-cli --api-endpoint https://.smartkey.io create-app --name kroxylicious --default-group topic-keks --groups topic-keks
-----
-
-Retrieve the API key for the app:
-
-[source,shell]
-----
-sdkms-cli --api-endpoint https://.smartkey.io get-app-api-key --name kroxylicious
-----
-
-The Record Encryption filter uses the API Key in its KMS configuration to authenticate to Fortanix DSM.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-key-creation.adoc b/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-key-creation.adoc
deleted file mode 100644
index 357f72f4..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-key-creation.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-// file included in the following:
-//
-// assembly-hashicorp-vault.adoc
-
-[id='con-vault-key-creation-{context}']
-= Creating HashiCorp Vault keys
-
-As the administrator, use either the HashiCorp UI or CLI to create AES-256 symmetric keys following your
-key naming convention. The key type must be `aes256-gcm96`, which is Vault's default key type.
-
-TIP: It is recommended to use a key rotation policy.
-
-If using the Vault CLI, the command will look like:
-
-[source, shell]
-----
-vault write -f transit/keys/KEK_trades type=aes256-gcm96 auto_rotate_period=90d
-----
diff --git a/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-plugin-configuration.adoc b/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-plugin-configuration.adoc
deleted file mode 100644
index 743e6f09..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-plugin-configuration.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-// file included in the following:
-//
-// assembly-configuring-record-encryption-filter
-
-[id='con-vault-plugin-configuration-{context}']
-= HashiCorp Vault plugin configuration
-
-For HashiCorp Vault, the KMS configuration used by the filter looks like this.
-Use the Vault Token and Vault Transit Engine URL values from the KMS setup.
-
-[source, yaml]
-----
-kms: VaultKmsService # <1>
-kmsConfig:
- vaultTransitEngineUrl: # <2>
- tls: # <3>
- # ...
- vaultToken: # <4>
- passwordFile: /opt/vault/token
-
-----
-<1> Specifies the name of the KMS provider. Use `VaultKmsService`.
-<2> xref:con-vault-setup-{context}[Vault Transit Engine URL] including the protocol part, such as `https:` or `http:`.
-<3> (Optional) TLS trust configuration.
-<4> File containing the Vault Token.
-
-include::../../../snippets/snip-tls-client-keystore.adoc[]
-
-include::../../../snippets/snip-tls-client-truststore.adoc[]
-
diff --git a/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-setup.adoc b/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-setup.adoc
deleted file mode 100644
index 44735646..00000000
--- a/docs/v0.13.0/_files/modules/record-encryption/hashicorp-vault/con-vault-setup.adoc
+++ /dev/null
@@ -1,151 +0,0 @@
-// file included in the following:
-//
-// assembly-hashicorp-vault.adoc
-
-[id='con-vault-setup-{context}']
-= Enable the Transit Engine
-
-The filter integrates with the {hashicorp-vault}/docs/secrets/transit[HashiCorp Vault *Transit
-Engine*].
-Vault does not enable the Transit Engine by default.
-It must be {hashicorp-vault}/docs/secrets/transit#setup[enabled] before it can be used by the filter.
-
-== Vault Transit Engine URL
-
-The Vault Transit Engine URL is required so the filter knows the location of the Transit Engine within the
-Vault instance.
-
-The URL is formed from the concatenation of the `Api Address` (reported by Vault reported by during
-{hashicorp-vault}/tutorials/getting-started/getting-started-dev-server#starting-the-dev-server[starts up]) with the
-complete path to Transit Engine, including the name of the engine itself. If
-{hashicorp-vault}/docs/enterprise/namespaces[Namespacing] is used on the Vault instance, the path needs to include the
-namespace(s). The URL will end with `/transit` unless the `-path` parameter was used when
-{hashicorp-vault}/docs/secrets/transit#setup[enabling the engine].
-
-If namespacing is not in use, the URL will look like this:
-
-[source,shell]
-----
-https://myvaultinstance:8200/v1/transit
-----
-
-If namespacing is in use, the path must include the namespaces. For example, if there is a parent namespace is `a` and
-a child namespace is `b`, the URL will look like this:
-
-[source,shell]
-----
-https://myvaultinstance:8200/v1/a/b/transit
-----
-
-If the name of the Transit engine was changed (using the `-path` argument to the `vault secrets enable transit` command)
-the URL will look like this:
-
-[source,shell]
-----
-https://myvaultinstance:8200/v1/mytransit
-----
-
-== Establish the naming convention for keys within Vault hierarchy
-
-Establish a naming convention for keys to keep the filter’s keys separate from those used by other systems.
-Here, we use a prefix of KEK_ for filter key name.
-Adjust the instructions if a different naming convention is used.
-
-== Role of the administrator
-
-To use the filter, an administrator or an administrative process must create the encryption keys within Vault, which
-are used by the xref:con-topic-encryption-overview-{context}[envelope encryption] process.
-
-The organization deploying the Record Encryption filter is responsible for managing this administrator or process.
-
-The administrator must have permissions to create keys beneath `transit/keys/KEK_*` in the Vault hierarchy.
-
-As a guideline, the minimal Vault policy required by the administrator is as follows:
-
-[source,shell]
-----
-path "transit/keys/KEK_*" {
- capabilities = ["read", "write"]
-}
-----
-
-== Establish an application identity for the filter
-
-The filter must authenticate to Vault in order to perform envelope encryption operations, such as generating and decrypting DEKs
-Therefore, a Vault identity with sufficient permissions must be created for the filter.
-
-Create a Vault policy for the filter:
-
-[source,shell]
-----
-vault policy write kroxylicious_encryption_filter_policy - << EOF
-path "transit/keys/KEK_*" {
- capabilities = ["read"]
-}
-path "/transit/datakey/plaintext/KEK_*" {
- capabilities = ["update"]
-}
-path "transit/decrypt/KEK_*" {
- capabilities = ["update"]
-}
-EOF
-----
-
-Create a {hashicorp-vault}/docs/concepts/tokens#periodic-tokens[Periodic] (long-lived) Vault Token
-for the filter:
-
-[source,shell]
-----
-vault token create -display-name "kroxylicious record encryption" \
- -policy=kroxylicious_encryption_filter_policy \
- -period=768h \ # <1>
- -no-default-policy \ # <2>
- -orphan # <3>
-
-----
-<1> Causes the token to be periodic (with every renewal using the given period).
-<2> Detach the "default" policy from the policy set for this token. This is done so the token has least-privilege.
-<3> Create the token with no parent. This is done so that expiration of a parent won't expire the token used by the filter.
-
-NOTE: The example token create command illustrates the use of `-no-default-policy`
-and `-orphan`. The use of these flags is not functionally important.
-You may adapt the configuration of the token to suit the standards required by your organization.
-
-The `token create` command yields the `token`. The `token` value is required later when configuring the vault within the
-filter.
-
-[source]
-----
-token hvs.CAESIFJ_HHo0VnnW6DSbioJ80NqmuYm2WlON-QxAPmiJScZUGh4KHGh2cy5KdkdFZUJMZmhDY0JCSVhnY2JrbUNEWnE
-token_accessor 4uQZJbEnxW4YtbDBaW6yVzwP
-token_policies [kroxylicious_encryption_filter_policy]
-----
-
-The token must be {hashicorp-vault}/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls[renewed]
-before expiration.
-It is the responsibility of the administrator to do this.
-
-This can be done with a command like the following:
-
-[source,shell]
-----
-vault token renew --accessor
-----
-
-== Testing the application identity for the filter using the CLI
-
-To test whether the application identity and the policy are working correctly, a
-https://raw.githubusercontent.com/kroxylicious/kroxylicious/main/scripts/validate_vault_token.sh[script] can be used.
-
-First, as the administrator, create a KEK in the hierarchy at this path `transit/keys/KEK_testkey`.
-
-[source,shell]
-----
-VAULT_TOKEN= validate_vault_token.sh
-----
-
-The script should respond `Ok`.
-If errors are reported check the policy/token configuration.
-
-`transit/keys/KEK_testkey` can now be removed.
-
diff --git a/docs/v0.13.0/_files/modules/record-validation/proc-record-validation.adoc b/docs/v0.13.0/_files/modules/record-validation/proc-record-validation.adoc
deleted file mode 100644
index b27aae4f..00000000
--- a/docs/v0.13.0/_files/modules/record-validation/proc-record-validation.adoc
+++ /dev/null
@@ -1,88 +0,0 @@
-// file included in the following:
-//
-// assembly-record-validation-filter.adoc
-
-[id='proc-record-validation-{context}']
-= (Preview) Setting up the Record Validation filter
-
-[role="_abstract"]
-This procedure describes how to set up the Record Validation filter.
-Provide the filter configuration and rules that the filter uses to check against Kafka record keys and values.
-
-.Prerequisites
-
-* An instance of Kroxylicious.
-For information on deploying Kroxylicious, see the link:{github}[samples and examples^].
-* A config map for Kroxylicious that includes the configuration for creating a virtual cluster.
-* Apicurio Registry (if wanting to use Schema validation).
-
-.Procedure
-
-. Configure a `RecordValidation` type filter.
-
-[source,yaml]
-----
-filterDefinitions:
- - name: my-record-validation
- type: RecordValidation
- config:
- rules:
- - topicNames: # <1>
- -
- keyRule:
- # <2>
- valueRule:
- # <3>
- defaultRule: # <4>
- keyRule:
- # <2>
- valueRule:
- # <3>
-----
-<1> List of topic names to which the validation rules will be applied.
-<2> Validation rules that are applied to the record's key.
-<3> Validation rules that are applied to the record's value.
-<4> (Optional) Default rule that is applied to any topics for which there is no explict rule defined.
-
-Replace the token `` in the YAML configuration with either a Schema Validation rule or a JSON Syntax Validation rule depending on your requirements.
-
-.Example Schema Validation Rule Definition
-
-The Schema Validation rule validates that the key or value matches a schema identified by its global ID within an Apicurio Schema Registry.
-
-If the key or value does not adhere to the schema, the record will be rejected.
-
-Additionally, if the kafka producer has embedded a global ID within the record it will be validated against the global ID defined by the rule. If they do not match, the record will be rejected. See the
-{apicurio-docs}/getting-started/assembly-using-kafka-client-serdes.html#_consumer_schema_configuration[Apicurio documentation^] for details
-on how the global ID could be embedded into the record.
-The filter supports extracting ID's from either the Apicurio `globalId` record header or from the initial bytes of the serialized content itself.
-
-[source,yaml]
-----
-schemaValidationConfig:
- apicurioGlobalId: 1001 # <1>
- apicurioRegistryUrl: http://registry.local:8080 # <2>
-allowNulls: true # <3>
-allowEmpty: true # <4>
-----
-<1> Apicurio registry global ID identifying the schema that will be enforced.
-<2> Apicurio Registry endpoint.
-<3> if `true`, the validator allows keys and or values to be `null`. The default is `false`.
-<4> if `true`, the validator allows keys and or values to be empty. The default is `false`.
-
-NOTE: Schema validation mode currently has the capability to enforce only JSON schemas (https://github.com/kroxylicious/kroxylicious/issues/1431[issue])
-
-.Example JSON Syntax Validation Rule Definition
-
-The JSON Syntax Validation rule validates that the key or value contains only syntactically correct JSON.
-
-[source,yaml]
-----
-syntacticallyCorrectJson:
- validateObjectKeysUnique: true # <1>
-allowNulls: true # <2>
-allowEmpty: true # <3>
-----
-<1> If `true`, the validator enforces that objects keys must be unique. The default is `false`.
-<2> if `true`, the validator allows keys and or values to be `null`. The default is `false`.
-<3> if `true`, the validator allows keys and or values to be empty. The default is `false`.
diff --git a/docs/v0.13.0/_files/modules/ref-glossary.adoc b/docs/v0.13.0/_files/modules/ref-glossary.adoc
deleted file mode 100644
index 4fd3edb5..00000000
--- a/docs/v0.13.0/_files/modules/ref-glossary.adoc
+++ /dev/null
@@ -1,10 +0,0 @@
-= Glossary
-
-API:: Application Programmer Interface.
-CA:: Certificate Authority. An organization that issues certificates.
-CR:: Custom Resource. An instance resource of a CRD. In other words, a resource of a kind that is not built into Kubernetes.
-CRD:: Custom Resource Definition. A Kubernetes API for defining Kubernetes API extensions.
-KMS:: Key Management System. A dedicated system for controlling access to cryptographic material, and providing operations which use that material.
-mTLS:: Mutual Transport Layer Security. A configuration of TLS where the client presents a certificate to a server, which the server authenticates.
-TLS:: The Transport Layer Security. A secure transport protocol where a server presents a certificate to a client, which the client authenticates. TLS was previously known as the Secure Sockets Layer (SSL).
-TCP:: The Transmission Control Protocol.
diff --git a/docs/v0.13.0/_files/record-encryption-guide/_assets b/docs/v0.13.0/_files/record-encryption-guide/_assets
deleted file mode 120000
index f6c9582d..00000000
--- a/docs/v0.13.0/_files/record-encryption-guide/_assets
+++ /dev/null
@@ -1 +0,0 @@
-../_assets
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/record-encryption-guide/assemblies b/docs/v0.13.0/_files/record-encryption-guide/assemblies
deleted file mode 120000
index ff41b88e..00000000
--- a/docs/v0.13.0/_files/record-encryption-guide/assemblies
+++ /dev/null
@@ -1 +0,0 @@
-../assemblies
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/record-encryption-guide/index.adoc b/docs/v0.13.0/_files/record-encryption-guide/index.adoc
deleted file mode 100644
index d514c5d7..00000000
--- a/docs/v0.13.0/_files/record-encryption-guide/index.adoc
+++ /dev/null
@@ -1,52 +0,0 @@
-:experimental:
-include::_assets/attributes.adoc[]
-
-:context: record-encryption
-:guide: record-encryption
-
-[id="using-book-{context}"]
-= Record Encryption Guide
-
-include::modules/record-encryption/con-about-{guide}-guide.adoc[leveloffset=+1]
-
-[role="_abstract"]
-The Kroxylicious Record Encryption filter enhances the security of Kafka messages.
-The filter uses industry-standard cryptographic techniques to apply encryption to Kafka messages, ensuring the confidentiality of data stored in the Kafka Cluster.
-By centralizing topic-level encryption, Kroxylicious provides streamlined protection across Kafka clusters.
-
-To use the filter, follow these steps:
-
-1. Set up a Key Management System (KMS)
-2. Establish encryption keys within the KMS for securing the topics
-3. Configure the filter within Kroxylicious
-
-The filter integrates with a Key Management Service (KMS), which is responsible for the safe storage of sensitive key material.
-Kroxylicious supports the following KMS providers:
-
-* HashiCorp Vault
-* AWS Key Management Service.
-ifdef::include-fortanix-dsm-kms[]
-* Fortanix DSM
-endif::[]
-
-You can provide implementations for your specific KMS systems.
-Additional KMS support may be added based on demand.
-
-//overview of the record encryption process
-include::modules/record-encryption/con-record-encryption-overview.adoc[leveloffset=+1]
-
-// preparing the KMS (might be done by a KMS admin, rather
-// than the person setting up the filter)
-include::assemblies/assembly-preparing-kms.adoc[leveloffset=+1]
-
-//configuring the record encryption filter
-include::assemblies/assembly-configuring-record-encryption-filter.adoc[leveloffset=+1]
-
-//monitoring the record encryption filter
-include::assemblies/assembly-monitoring-record-encryption-filter.adoc[leveloffset=+1]
-
-//operational issues affecting the record encryption filter
-include::assemblies/assembly-operations-record-encryption-filter.adoc[leveloffset=+1]
-
-//trademark notices
-include::_assets/trademarks.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/record-encryption-guide/modules b/docs/v0.13.0/_files/record-encryption-guide/modules
deleted file mode 120000
index 464b823a..00000000
--- a/docs/v0.13.0/_files/record-encryption-guide/modules
+++ /dev/null
@@ -1 +0,0 @@
-../modules
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/record-encryption-guide/snippets b/docs/v0.13.0/_files/record-encryption-guide/snippets
deleted file mode 120000
index 9d58b92e..00000000
--- a/docs/v0.13.0/_files/record-encryption-guide/snippets
+++ /dev/null
@@ -1 +0,0 @@
-../snippets/
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/snippets/snip-operator-namespace-sed.adoc b/docs/v0.13.0/_files/snippets/snip-operator-namespace-sed.adoc
deleted file mode 100644
index c40cfdcf..00000000
--- a/docs/v0.13.0/_files/snippets/snip-operator-namespace-sed.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-On Linux, use:
-+
-[source, subs="+quotes"]
-----
-sed -i 's/namespace: .\*/namespace: my-kroxylicious-operator-namespace/' install/*.yaml
-----
-+
-On MacOS, use:
-+
-[source, subs="+quotes"]
-----
-sed -i '' 's/namespace: .\*/namespace: my-kroxylicious-operator-namespace/' install/*.yaml
-----
diff --git a/docs/v0.13.0/_files/snippets/snip-tls-cipher-suite.adoc b/docs/v0.13.0/_files/snippets/snip-tls-cipher-suite.adoc
deleted file mode 100644
index 57b964af..00000000
--- a/docs/v0.13.0/_files/snippets/snip-tls-cipher-suite.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-:_mod-docs-content-type: SNIPPET
-
-A cipher suite is a set of cryptographic algorithms that together provide the security guarantees offered by TLS.
-During TLS negotiation, a server and client agree on a common cipher suite that they both support.
-
-Some older cipher suites are now considered insecure, but may be enabled on the Kafka cluster to allow older clients to connect.
-
-The cipher suites enabled by default in the proxy depend on the JVM used in the proxy image and the TLS protocol version that is negotiated.
-
-To prevent TLS downgrade attacks, you can disable cipher suites known to be insecure or no longer recommended.
-However, the proxy and the cluster must support at least one cipher suite in common.
-
-IMPORTANT: It is good practice to disable insecure cipher suites.
\ No newline at end of file
diff --git a/docs/v0.13.0/_files/snippets/snip-tls-client-keystore.adoc b/docs/v0.13.0/_files/snippets/snip-tls-client-keystore.adoc
deleted file mode 100644
index 3b9b1b36..00000000
--- a/docs/v0.13.0/_files/snippets/snip-tls-client-keystore.adoc
+++ /dev/null
@@ -1,21 +0,0 @@
-:_mod-docs-content-type: SNIPPET
-
-A TLS client certificate can be specified using a PKCS#12 or JKS key store file.
-
-.Example TLS client certificate configuration using a PKCS#12 key store file
-[source,yaml]
-----
-key:
- storeFile: /opt/cert/server.p12 # <1>
- storeType: PKCS12 # <2>
- storePassword: # <3>
- passwordFile: /opt/cert/store.password
- keyPassword: # <4>
- passwordFile: /opt/cert/key.password
-
-----
-<1> `storeFile` specifies PKCS#12 file
-<2> `storeType` speficies what the keystore file type is. Supported values include `PKCS12` and `JKS`.
-<3> Optionally, a keystore file password may be specified.
-<4> Optionally, a password may be specified for the key entry within the file.
-
diff --git a/docs/v0.13.0/_files/snippets/snip-tls-client-truststore.adoc b/docs/v0.13.0/_files/snippets/snip-tls-client-truststore.adoc
deleted file mode 100644
index de143d1d..00000000
--- a/docs/v0.13.0/_files/snippets/snip-tls-client-truststore.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-:_mod-docs-content-type: SNIPPET
-
-A set of trust anchors for the TLS client can be specified using a PKCS#12 or JKS key store file.
-
-.Example TLS client trust change configuration using a PKCS#12 key store file
-[source,yaml]
-----
-trust:
- storeFile: /opt/cert/server.p12 # <1>
- storeType: PKCS12 # <2>
- storePassword: # <3>
- passwordFile: /opt/cert/store.password
-----
-<1> `storeFile` specifies PKCS#12 file
-<2> `storeType` specifies what the keystore file type is. Supported values include `PKCS12` and `JKS`.
-<3> Optionally, a keystore file password may be specified.
-
-
diff --git a/docs/v0.13.0/_files/snippets/snip-tls-protocol-versions.adoc b/docs/v0.13.0/_files/snippets/snip-tls-protocol-versions.adoc
deleted file mode 100644
index 47cd4d1e..00000000
--- a/docs/v0.13.0/_files/snippets/snip-tls-protocol-versions.adoc
+++ /dev/null
@@ -1,10 +0,0 @@
-:_mod-docs-content-type: SNIPPET
-
-Some older versions of TLS (and SSL before it) are now considered insecure.
-These versions remain enabled by default in order to maximize interoperability between TLS clients and servers that only support older versions.
-
-If the Kafka cluster than you want to connect to supports newer TLS versions, you can disable the proxy's support for older, insecure versions.
-For example, if the Kafka cluster supports TLSv1.1, TLSv1.2 and TLSv1.3 you might choose to enable only TLSv1.3 support.
-This would reduce the susceptibility to a TLS downgrade attack.
-
-IMPORTANT: It is good practice to disable insecure protocol versions.
\ No newline at end of file
diff --git a/docs/v0.13.0/developer-guide/index.adoc b/docs/v0.13.0/developer-guide/index.adoc
deleted file mode 100644
index 96fe1c8d..00000000
--- a/docs/v0.13.0/developer-guide/index.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Kroxylicious Developer Guide v0.13.0
----
-
-include::../_files/developer-guide/index.adoc[leveloffset=0]
-
diff --git a/docs/v0.13.0/developer-guide/index.html b/docs/v0.13.0/developer-guide/index.html
new file mode 100644
index 00000000..57cf53e8
--- /dev/null
+++ b/docs/v0.13.0/developer-guide/index.html
@@ -0,0 +1,6 @@
+---
+title: Kroxylicious Developer Guide v0.13.0
+layout: redirect
+target: /documentation/0.13.0/html/developer-guide
+delay: 1
+---
diff --git a/docs/v0.13.0/index.adoc b/docs/v0.13.0/index.adoc
deleted file mode 100644
index 26aef563..00000000
--- a/docs/v0.13.0/index.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Kroxylicious Proxy v0.13.0
----
-
-include::_files/index.adoc[leveloffset=0]
-
diff --git a/docs/v0.13.0/index.html b/docs/v0.13.0/index.html
new file mode 100644
index 00000000..14b2aae3
--- /dev/null
+++ b/docs/v0.13.0/index.html
@@ -0,0 +1,7 @@
+---
+title: Kroxylicious Proxy v0.13.0
+layout: redirect
+target: /documentation/0.13.0/
+delay: 1
+---
+
diff --git a/docs/v0.13.0/kroxylicious-operator/index.adoc b/docs/v0.13.0/kroxylicious-operator/index.adoc
deleted file mode 100644
index 45375430..00000000
--- a/docs/v0.13.0/kroxylicious-operator/index.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Kroxylicious Operator v0.13.0
----
-
-include::../_files/kroxylicious-operator/index.adoc[leveloffset=0]
-
diff --git a/docs/v0.13.0/kroxylicious-operator/index.html b/docs/v0.13.0/kroxylicious-operator/index.html
new file mode 100644
index 00000000..d125fd4a
--- /dev/null
+++ b/docs/v0.13.0/kroxylicious-operator/index.html
@@ -0,0 +1,7 @@
+---
+title: Kroxylicious Operator v0.13.0
+layout: redirect
+target: /documentation/0.13.0/html/kroxylicious-operator
+delay: 1
+---
+
diff --git a/docs/v0.13.0/kroxylicious-proxy/index.adoc b/docs/v0.13.0/kroxylicious-proxy/index.adoc
deleted file mode 100644
index a6b5948a..00000000
--- a/docs/v0.13.0/kroxylicious-proxy/index.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Kroxylicious Proxy v0.13.0
----
-
-include::../_files/kroxylicious-proxy/index.adoc[leveloffset=0]
-
diff --git a/docs/v0.13.0/kroxylicious-proxy/index.html b/docs/v0.13.0/kroxylicious-proxy/index.html
new file mode 100644
index 00000000..b34da936
--- /dev/null
+++ b/docs/v0.13.0/kroxylicious-proxy/index.html
@@ -0,0 +1,7 @@
+---
+title: Kroxylicious Proxy v0.13.0
+layout: redirect
+target: /documentation/0.13.0/html/kroxylicious-proxy
+delay: 1
+---
+
diff --git a/docs/v0.13.0/record-encryption-guide/index.adoc b/docs/v0.13.0/record-encryption-guide/index.adoc
deleted file mode 100644
index 24094975..00000000
--- a/docs/v0.13.0/record-encryption-guide/index.adoc
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Kroxylicious Record Encryption Guide v0.13.0
----
-
-include::../_files/record-encryption-guide/index.adoc[leveloffset=0]
-
diff --git a/docs/v0.13.0/record-encryption-guide/index.html b/docs/v0.13.0/record-encryption-guide/index.html
new file mode 100644
index 00000000..9f6eae52
--- /dev/null
+++ b/docs/v0.13.0/record-encryption-guide/index.html
@@ -0,0 +1,7 @@
+---
+title: Kroxylicious Record Encryption Guide v0.13.0
+layout: redirect
+target: /documentation/0.13.0/html/record-encryption-guide
+delay: 1
+---
+