ビジョン：セキュアなイベント処理とイベント検出機能の向上 ¶
公開日：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 の採用者にとって多くの課題が生じます。
今後の解決策は、イベントを受信するための HTTPS エンドポイントを提供する Knative ブローカーとチャネルにあります。ただし、これらのエンドポイントは通常、公開 DNS 名（例：svc.cluster.local など）を持たないため、クラスタまたは組織に固有の非公開 CA によって署名する必要があります。
これを容易にするために、イベントプロデューサーは、Knative リソースのメタデータから、ブローカーまたはチャネル証明書の署名に使用された CA ルートを認識できるようになります。
詳細については、トランスポート暗号化機能 を参照してください。
承認と承認ポリシー¶
イベント駆動型アーキテクチャは、組織のサイロと障壁を削減し、レジリエントなシステムを促進し、ビジネスの俊敏性を高めることを目的としています。しかし、このビジョンを実現するには、イベントの承認ポリシーと堅牢な保護策を実装して、セキュリティとデータの品質を確保する必要があります。
イベント承認ポリシーは、Knative ブローカーやチャネルなど、特定のイベントハブにイベントを送信する権限を持つユーザーを決定する承認ポリシーの重要な要件に対処します。さらに、これらのポリシーは、スキーマやその他の関連要素を含む、送信されるイベントの有効なコンテンツを管理します。
承認と承認ポリシーは、以下で詳しく説明するように、セキュアなイベント処理の側面とイベント検出の領域を橋渡しする重要な機能です。
イベント検出機能の向上¶
イベント検出は、開発者がさまざまなレベルのサービスドキュメントを調べることなく、消費できるイベントとイベントの外観を理解するのに役立ちます。
Knative は、Knative イベントングシステムで使用可能なイベントの種類を検出できる EventType API を定義しています。これにより、開発者はどのような種類のイベントをリッスンして処理できるかを理解するのに役立ち、大量のイベントが生成されるシステムでは特に役立ちます。
しかし、現在、EventType は残念ながら十分に使用されておらず、Knative Source ダックタイプと Knative Broker API の組み合わせを実装するソースに限定されています。
Knative Eventing の開発者エクスペリエンスを向上させるために、いくつかの方法でイベント検出機能を強化しています！
- 自動イベントタイプの作成
- ブローカーAPIを超えた使用
- イベントタイプの定義
自動イベントタイプの作成¶
現在、EventType API では、開発者が手動で EventType オブジェクトを作成する必要があります。
この問題に対処するために、EventType の自動作成をサポートするために有効にできるオプションの機能フラグを導入します。
詳細については、eventtype-auto-creation機能ドキュメント を参照してください。
この機能は、組織全体を流れるイベントを文書化および検出する迅速な方法として考えていますが、手動でEventTypeを作成することも可能です。
Knative ブローカー以外のサポート¶
現在、EventType API は、コンシューマーがそのようなイベントを購読するために使用できる Knative ブローカーの名前を表すbrokerと呼ばれるフィールドを含むため、Knative Broker API を使用する場合にのみ使用できます。
EventType API は.spec.brokerフィールドを非推奨とし、チャネルやシンクを含む任意の Knative リソースを参照できる.spec.referenceフィールドを追加します。
これは、イベントタイプメタデータの利用をBroker APIのみに制限する制約を解消し、EventType APIを他のあらゆるリソースで使用できるようにします。
イベントタイプ定義のCRD¶
EventTypeオブジェクトは、ソースシステムから積極的に送信されているイベントを表します。
イベント駆動アーキテクチャを構築する際には、多くの場合、イベント構造とそのメタデータが、ソースシステムがそのようなイベントを送信する前に設計段階で決定され、文書化されます。
EventTypeDefinition APIは、チームやシステムインテグレータが他のチームに対して、そのようなイベントタイプが潜在的に使用可能であることを文書化するために使用できるオブジェクトタイプになります。
詳細については、機能追跡ドキュメントを参照してください。
結論¶
ご覧のとおり、私たちはKnative Eventingプロジェクトの推進に尽力しています。上記は、セキュアなイベント処理やイベント検出性の向上などのトピックが、すべてのKnative Eventingユーザーの開発者エクスペリエンスを向上させるために取り組まれていることを示しています。
しかし、まだ終わりではありません！私たちはKnative Eventingの改善に情熱を注いでおり、Kubernetes向けのイベント駆動アーキテクチャの分野でも革新を続けています。しかし、私たちだけではできません。皆様の力も必要です！
興味があり、参加したい場合は、Github Projectsをご覧ください。または、Slackチャンネルに参加してください。皆様のご協力と貢献は、Knativeの継続的な成功に不可欠です。共に、Kubernetes上のイベント駆動型アプリケーションの未来を形作っていきましょう！