願景：安全事件處理和改進的事件可發現性 ¶

發佈於：2023-08-07，修訂於：2024-01-17

願景：安全事件處理和改進的事件可發現性¶

作者：Pierangelo Di Pilato，Red Hat 資深軟體工程師，Matthias Weßendorf，Red Hat 資深首席軟體工程師

Knative Eventing 的下一步是什麼？¶

Knative Eventing 已取得重大進展，並鞏固其作為 Kubernetes 上事件驅動應用程式平台的地位。然而，我們在這個專案上的旅程遠未結束；我們致力於其持續發展。我們的努力包括增強現有的 API 和引入新功能，以進一步增強 Knative Eventing 的能力。以下，我們提供未來幾個月即將推出的計劃的高階概述。

我們重視您的回饋，因為它在塑造專案的未來方面起著至關重要的作用。如果您發現任何缺少的功能或需要改進的地方，請隨時與我們分享您的想法。您的意見對我們來說非常寶貴！

安全事件處理¶

安全事件處理是指以安全且受信任的方式處理和分析事件或資料串流的實務。事件可以包括各種類型的資料，例如使用者互動、系統日誌、感測器讀數、網路流量或任何其他形式的即時或近即時資料。

安全事件處理的主要目標是確保已處理事件的機密性、完整性和可用性，同時維護基礎資料的隱私和安全。

傳輸加密¶

目前，叢集內的事件傳遞缺乏加密，這限制了可以傳輸的事件類型——通常是合規性價值較低或合規性要求較寬鬆的事件。或者，管理員必須求助於服務網格或加密的 CNI 來加密流量，這為 Knative Eventing 的採用者帶來了多重挑戰。

即將推出的解決方案在於 Knative Broker 和 Channel，它們將提供 HTTPS 端點來接收事件。但是，由於這些端點通常缺乏公用 DNS 名稱（例如，svc.cluster.local 或類似名稱），因此它們必須由特定於叢集或組織的非公用 CA 簽署。

為了方便起見，事件產生者將能夠從 Knative 資源的中繼資料中得知用於簽署 Broker 或 Channel 憑證的 CA 根憑證。

如需更多詳細資訊，請參閱傳輸加密功能

授權和許可原則¶

事件驅動架構旨在減少組織孤島和障礙，促進彈性系統和增強業務敏捷性。然而，要實現這一願景，需要實施事件許可原則和健全的保障措施，以確保安全和資料品質。

事件許可原則將解決授權原則的關鍵需求，確定誰有權將事件傳送到特定的事件中心，例如 Knative Broker 或 Channel。此外，這些原則將管理哪些內容被視為傳輸事件的有效內容，包括結構描述和其他相關元素。

授權和許可原則是將安全事件處理方面與事件探索領域聯繫起來的關鍵功能，如下所述。

改進的事件探索¶

事件探索可協助開發人員了解他們可以取用哪些事件，以及事件的外觀，而無需深入研究各個層級的服務文件。

Knative 定義了一個 EventType API，允許探索 Knative Eventing 系統中可用的事件類型。這可協助開發人員了解可以監聽和處理哪些類型的事件，這在產生大量事件的系統中特別有用。

然而，目前 EventType 不幸地未被充分利用，並且僅限於實作 Knative Source Ducktype 與 Knative Broker API 結合使用的來源。

為了改進 Knative Eventing 的開發人員體驗，我們正在以幾種方式增強事件探索！

自動事件類型建立
超出 Broker API 的使用範圍
事件類型定義

自動事件類型建立¶

目前，EventType API 要求開發人員手動建立 EventType 物件。

為了解決此問題，我們引入了一個可選的功能旗標，可以啟用以支援自動建立 EventType。

如需更多詳細資訊，請參閱 eventtype-auto-creation 功能文件

我們將此功能視為記錄和探索在組織中流動的事件的一種快速方法，但是，仍然可以手動建立 EventType。

支援不只是 Knative Broker 的更多功能¶

目前，EventType API 僅在使用 Knative Broker API 時才可使用，因為它包含一個名為 broker 的欄位，該欄位表示取用者可以用來訂閱此類事件的 Knative Broker 的名稱。

EventType API 將棄用 .spec.broker 欄位，並新增 .spec.reference 欄位，該欄位可以參考任何 Knative 資源，包括通道和接收器。

這消除了僅將事件類型中繼資料與 Broker API 一起使用的限制，並允許將 EventType API 與任何其他資源一起使用。

事件類型定義的 CRD¶

EventType 物件代表來源系統正在主動傳送的事件。

許多時候，在建構事件驅動架構時，團隊會有一個設計階段，在此階段中會決定並記錄事件結構及其中繼資料，然後再由任何來源系統傳送此類事件。

EventTypeDefinition API 將會是團隊和系統整合商可使用來向其他團隊說明此類事件類型可能可用的物件類型。

如需更多詳細資訊，請參閱功能追蹤文件

結論¶

如您所見，我們致力於推動 Knative Eventing 專案的發展。上述內容顯示，諸如安全事件處理或改善事件可探索性等主題，旨在提升所有 Knative Eventing 使用者的開發體驗。

然而，我們並未止步於此！我們熱衷於改進 Knative Eventing，並持續在 Kubernetes 的事件驅動架構領域進行創新。但我們無法單獨完成這一切：我們也需要您的協助！

如果您感到好奇並想參與其中，請探索我們在 Github 專案中的專案，或隨時加入我們的 Slack 頻道。您的合作與貢獻對於 Knative 的持續成功至關重要。讓我們攜手共創 Kubernetes 上事件驅動應用程式的未來！