-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #3 from pierDipi/my-edits-kne-vision
Add a few edits to what's next in Knative Eventing blog post
- Loading branch information
Showing
1 changed file
with
87 additions
and
36 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,88 +1,139 @@ | ||
| # Secure Event processing and improved Event discoverability | ||
|
|
||
| **Authors: Pierangelo Di Pilato, Senior Software Engineer @ Red Hat, Matthias Weßendorf, Senior Principal Software Engineer @ Red Hat** | ||
| **Authors: Pierangelo Di Pilato, Senior Software Engineer @ Red Hat, Matthias Weßendorf, Senior | ||
| Principal Software Engineer @ Red Hat** | ||
|
|
||
| **Date: 2023-07-27** | ||
|
|
||
| ## What is next in Knative Eventing? | ||
|
|
||
| Knative Eventing has come a long way and has established itself as the goto platform on Kubernetes for event-driven applications. However we are not done with the project and we continue to evolve it. We are improving existing APIs and adding new features to Knative Eventing as well. Below is a high level overview of what we are currently doing for the next couple of months. | ||
| Knative Eventing has made significant strides and solidified its position as the platform on | ||
| Kubernetes for event-driven applications. However, our journey with the project is far from over; we | ||
| are committed to its ongoing evolution. Our efforts involve enhancing existing APIs and introducing | ||
| new features to further empower Knative Eventing. Below, we provide a high-level overview of our | ||
| upcoming initiatives for the next months. | ||
|
|
||
| Please keep in mind that we need your feedback as well! If there are missing features or needed improvements, please speak up and tell. | ||
| We value your feedback, as it plays a crucial role in shaping the project's future. If you spot any | ||
| missing features or identify areas needing improvement, please don't hesitate to share your thoughts | ||
| with us. Your input is invaluable to us! | ||
|
|
||
| ## Secure Event Processing | ||
|
|
||
| Secure event processing refers to the practice of processing and analyzing events or data streams in a secure and trusted manner. Events can include various types of data, such as user interactions, system logs, sensor readings, network traffic, or any other form of real-time or near-real-time data. | ||
| Secure event processing refers to the practice of processing and analyzing events or data streams in | ||
| a secure and trusted manner. Events can include various types of data, such as user interactions, | ||
| system logs, sensor readings, network traffic, or any other form of real-time or near-real-time | ||
| data. | ||
|
|
||
| The primary goal of secure event processing is to ensure the confidentiality, integrity, and availability of the processed events while maintaining the privacy and security of the underlying data. | ||
| The primary goal of secure event processing is to ensure the confidentiality, integrity, and | ||
| availability of the processed events while maintaining the privacy and security of the underlying | ||
| data. | ||
|
|
||
| ### Transport encryption | ||
|
|
||
| Currently, event delivery within the cluster is unencrypted. This limits the types of events which can be transmitted to those of low compliance value (or a relaxed compliance posture) or, alternatively, forces administrators to use a service mesh or encrypted CNI to encrypt the traffic, which poses many challenges to Knative Eventing adopters. | ||
| Presently, event delivery within the cluster lacks encryption, imposing limitations on the types of | ||
| events that can be transmitted—usually those of low compliance value or with a relaxed compliance | ||
| posture. Alternatively, administrators must resort to a service mesh or encrypted CNI to encrypt the | ||
| traffic, introducing multiple challenges for Knative Eventing adopters. | ||
|
|
||
| Knative Brokers and Channels will provide HTTPS endpoints to receive events. Given that these endpoints typically do not have public DNS names (e.g. svc.cluster.local or the like), these need to be signed by a non-public CA (cluster or organization specific CA). | ||
| The forthcoming solution lies in Knative Brokers and Channels, which will offer HTTPS endpoints to | ||
| receive events. However, since these endpoints typically lack public DNS names (e.g., | ||
| svc.cluster.local or similar), they must be signed by a non-public CA, specific to the cluster or | ||
| organization. | ||
|
|
||
| Event producers will be able to determine the CA root used to sign the Broker or Channel certificate from the Knative resource’s metadata. | ||
| To facilitate this, event producers will have the ability to know the CA root used to sign the | ||
| Broker or Channel certificate from the Knative resource's metadata. | ||
|
|
||
| For more information, please refer to the [feature track document](https://docs.google.com/document/d/1H-x_oji8LqkCyd7tlsSyclmUe7FAmEJPgRxOU_0pkn8/edit). | ||
| For more detailed information, please refer to | ||
| the [transport-encryption feature](https://github.com/knative/docs/pull/5642) | ||
|
|
||
| ### Sender identity | ||
|
|
||
| Currently, event delivery within the cluster is unauthenticated, and an event consumer cannot determine the identity of any sender. | ||
|
|
||
| By sending the identity of the event sender along with the events, event receivers can start implementing access control features. | ||
|
|
||
| For more information, please refer to the [feature track document](https://docs.google.com/document/d/1e7UgNTkL0Br5Da09Rg2ieVmhKJo4VXuBj-mHT9NCujY/edit). | ||
| /* TODO use real feature docs link once PR above is in */ | ||
|
|
||
| ### Authorization and admission policies | ||
|
|
||
| Event-driven architecture is meant to lower organizations' silos and barriers, make systems more resilient and ultimately increase business agility, however, this is not possible without event admission policies and safeguards for security and data quality. | ||
| Event-driven architecture aims to reduce organizational silos and barriers, promoting resilient | ||
| systems and enhancing business agility. However, achieving this vision necessitates the | ||
| implementation of event admission policies and robust safeguards to ensure security and data | ||
| quality. | ||
|
|
||
| Event admission policies will address the need to have authorization policies regarding who is allowed to send events to a given event hub, like a Knative Broker or Channel, as well as what they accept as valid content for events sent to them (schemas, etc). | ||
| Event admission policies will tackle the critical requirement of authorization policies, determining | ||
| who has the privilege to send events to a specific event hub, such as a Knative Broker or Channel. | ||
| Additionally, these policies will govern what content is deemed valid for the events being | ||
| transmitted, including schemas and other related elements. | ||
|
|
||
| Authorization and admission policies will be the feature that will bridge the secure event processing topic to the event discovery topic, below. | ||
| Authorization and admission policies serve as the pivotal feature bridging the secure event | ||
| processing aspect with the event discovery realm, as detailed below. | ||
|
|
||
| ## Improved Event discovery | ||
|
|
||
| Event discovery helps developers to understand which events they can consume and how the events look like, without having to dig through various levels of service documentation. | ||
| Event discovery helps developers to understand which events they can consume and how the events look | ||
| like, without having to dig through various levels of service documentation. | ||
|
|
||
| Knative defines an EventType API which allows for discovery of the types of events that are available in the Knative Eventing system. This helps developers understand what kinds of events can be listened to and processed, which can be particularly helpful in systems with a large number of events being produced. | ||
| Knative defines an EventType API which allows for discovery of the types of events that are | ||
| available in the Knative Eventing system. This helps developers understand what kinds of events can | ||
| be listened to and processed, which can be particularly helpful in systems with a large number of | ||
| events being produced. | ||
|
|
||
| However currently the EventType is unfortunately underused and is limited to sources which implement the [Knative Source Ducktype](https://github.com/knative/pkg/blob/aef227e72ead466e1ff7a5dddca2c171b0d5f128/apis/duck/v1/source_types.go#L40), in combination with the Knative Broker API. | ||
| However currently the EventType is unfortunately underused and is limited to sources which implement | ||
| the Knative Source Ducktype in combination with the Knative Broker API. | ||
|
|
||
| In order to improve the developer experience of Knative Eventing we are enhancing the event discovery in a couple of ways! | ||
| In order to improve the developer experience of Knative Eventing we are enhancing the event | ||
| discovery in a couple of ways! | ||
|
|
||
| * Automatic event type creation | ||
| * Usage beyond the broker API | ||
| * Event Type definitions | ||
|
|
||
| ### Automatic Event Type creation | ||
|
|
||
| Today the EventType API is limited to Source-Duck compliant sources, and only usable in combination with the Knative Broker API. | ||
| Currently, the `EventType` API requires developers to create `EventType` objects manually. | ||
|
|
||
| However when using the Broker with a 3rd party integration, such as regular deployments or even CLI tools like `kn event send` the EventType is not created automatically! We do not see any EvenType information for these common usage patterns. | ||
| To address this problem we introduce an optional feature flag which can be _enabled_ in order to have support for an automatic creation of EventTypes. | ||
| To address this problem we introduce an optional feature flag which can be _enabled_ in order to | ||
| have support for an automatic creation of EventTypes. | ||
|
|
||
| Details can be found in the matching [feature track document](https://docs.google.com/document/d/1H8-mkMs5HWd3U7TT6KAWgU9ltDxqZv25Wls-6c4lneA/edit). | ||
| For more detailed information, please refer to | ||
| the [`eventtype-auto-creation` feature documentation](./../../../docs/eventing/experimental-features/eventtype-auto-creation.md) | ||
|
|
||
| ### Support for more than just Brokers | ||
| We see this feature as a quick way of documenting and discovering events that are flowing across an | ||
| organization, however, manually creating `EventType`s is still possible. | ||
|
|
||
| The EventType API will deprecate the `.spec.broker` field and replace it with a `.spec.reference`, which can be any Knative Resource, such a Channel, a Sink, or even a Database. | ||
| ### Support for more than just Knative Brokers | ||
|
|
||
| The good news is: This breaks the limitation to use the event type metadata with the Broker API only. Even when there is no filter on Channel/Subscription APIs, it is still important to know what event types are emitted to components like Channels or Sinks! | ||
| Currently, the `EventType` API is usable only when using the Knative Broker API because it contains | ||
| a field called `broker` which represents the name of the Knative Broker that consumers can use to | ||
| subscribe to such events. | ||
|
|
||
| The EventType API will deprecate the `.spec.broker` field and add a `.spec.reference` field, | ||
| which can reference any Knative resource, including channels and sinks. | ||
|
|
||
| This removes the limitation to use the event type metadata with the Broker API | ||
| only and allows using the `EventType` API with any other resource. | ||
|
|
||
| ### CRD for Event Type Definitions | ||
|
|
||
| The above limitations show that event types are only discoverable when there are running workloads, such as a PingSource sending events to a broker. Without this connection it is not possible to tell what categories of event types are generally available in Knative Eventing installation. | ||
| `EventType` objects represents events that are actively been sent by a source system. | ||
|
|
||
| Many times, when building event-driven architectures, teams have a design phase where the event | ||
| structure and their metadata are decided and documented before having any source system sending | ||
| such events. | ||
|
|
||
| To address this problem, Knative Eventing will have a new EventTypeDefinition metadata CRD that captures this information independently of running applications. | ||
| The `EventTypeDefinition` API will be the object types that teams and system integrators can use | ||
| to document to other teams that such event types are _potentially_ usable. | ||
|
|
||
| Details can be found in the matching [feature track document](https://docs.google.com/document/d/1vwEWtAm28g_QY9j0b63h8sRpGhvyB1K5ViNr8X3vIiM/edit). | ||
| For more detailed information, please refer to | ||
| the [feature track document](https://docs.google.com/document/d/1vwEWtAm28g_QY9j0b63h8sRpGhvyB1K5ViNr8X3vIiM/edit) | ||
|
|
||
| ## Conclusion | ||
|
|
||
| As you can see we are committed to move the Knative Eventing project forward. The above shows that topics like secure event processing or improved event discoverability are addressed to improve the developer experience for all Knative Eventing users. | ||
| As you can see we are committed to move the Knative Eventing project forward. The above shows that | ||
| topics like secure event processing or improved event discoverability are addressed to improve the | ||
| developer experience for all Knative Eventing users. | ||
|
|
||
| However, we are not done! We are passionate about improving Knative Eventing and also continue to innovate in the area of event driven architectures for Kubernetes. But we can not just do this alone: We also need your help! | ||
| However, we are not done! We are passionate about improving Knative Eventing and also continue to | ||
| innovate in the area of event driven architectures for Kubernetes. But we can not just do this | ||
| alone: We also need your help! | ||
|
|
||
| If you are curious, please check out the [Github Projects](https://github.com/orgs/knative/projects) we have or swing by in our several [Slack channels](https://knative.dev/docs/community/#communication-channels). | ||
| If you're curious and want to get involved, please explore | ||
| the [Github Projects](https://github.com/orgs/knative/projects) we have or feel free | ||
| to join us in our [Slack channels](https://knative.dev/docs/community/#communication-channels). Your | ||
| collaboration and contributions are invaluable to the continued success of Knative. | ||
| Together, we can shape the future of event-driven applications on Kubernetes! |