What's New in Knative Eventing: Security, Discovery, Int... Pierangelo Di Pilato & Christoph Stäbler

What's New in Knative Eventing: Security, Discovery, Integrations, and Job Sync

Speakers: Pierangelo Di Pilato, Software Engineer, Red Hat; Christoph Stäbler, Software Engineer, Red Hat

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=6usWUdJMyHY

Overview

This talk, presented by Pierangelo Di Pilato and Christoph Stäbler from Red Hat, provides a comprehensive update on the latest advancements in Knative Eventing, a crucial component for building serverless, event-driven applications on Kubernetes. The speakers delve into significant new features rolled out over the past 12-18 months, focusing on enhancing security, simplifying integrations with third-party services, improving event discoverability, enabling long-running event processing, and facilitating declarative event transformations.

The core objective of these updates is to address critical enterprise requirements for secure, robust, and developer-friendly event-driven architectures. By introducing native support for transport encryption, authentication, and fine-grained authorization, Knative Eventing significantly hardens its security posture. Concurrently, new integration capabilities with services like AWS SQS and an innovative event discovery API aim to streamline the development experience, making it easier for users to connect to and understand the vast landscape of event sources.

This article will explore these advancements in detail, highlighting how Knative Eventing is evolving to meet the complex demands of modern cloud-native applications. From securing event delivery end-to-end to abstracting away boilerplate code for event transformations, the features discussed represent a substantial leap forward in making eventing on Kubernetes more powerful, secure, and accessible for developers and platform engineers alike.

Background

▶ Watch: Introduction and agenda for Knative Eventing updates (0:00)

Knative Eventing, at its core, is designed to enable the creation of loosely coupled, event-driven microservices on Kubernetes. It provides abstractions for event sources, brokers, and sinks, facilitating the flow of events between different components. However, like many evolving cloud-native projects, it has historically faced challenges in certain areas that are critical for enterprise adoption and developer productivity.

Initially, Knative Eventing did not enforce security on event delivery by default. This meant that event traffic was often unencrypted, unauthorized, and unauthenticated, posing significant risks in production environments where sensitive data might be exchanged. While service meshes like Istio could be integrated for some security aspects, a native, opinionated security layer was a frequent request from the community. Organizations building event-driven systems require robust mechanisms to ensure data confidentiality, integrity, and controlled access to event streams.

Furthermore, connecting Knative Eventing to external, third-party services—especially public cloud offerings—often required custom solutions. Users typically had to leverage the generic ContainerSource or write their own bespoke sources, leading to increased development and maintenance overhead. While projects like Apache Camel K offered extensive connectors, a more native and streamlined integration path within Knative Eventing itself was needed to reduce friction and improve the out-of-the-box experience.

Finally, the proliferation of event sources and types, both internal and external, created a significant hurdle for developers: event discovery and understanding. Without clear documentation or standardized schemas, developers struggled to ascertain what events a particular source produced, their structure, and how to consume them effectively. This often led to time-consuming manual inspection or trial-and-error, hindering rapid application development. Addressing these pain points was crucial for Knative Eventing to mature into a truly comprehensive and enterprise-ready platform.

Key Findings

▶ Watch: Overview of 3 new key security features (2:00)

The talk highlights several key findings and contributions that significantly enhance Knative Eventing's capabilities and address long-standing challenges:

• Comprehensive Security Features: Knative Eventing now offers native, robust security mechanisms for event delivery. This includes transport encryption via TLS for HTTP endpoints, authentication via OpenID Connect (OIDC) to verify event sender identities, and authorization via Event Policies to define fine-grained access rules for event ingress. These features move Knative Eventing from an insecure-by-default model to one that supports secure, enterprise-grade event-driven architectures.

• Native Third-Party Integrations: The introduction of Integration Source and Integration Sync provides native support for connecting to popular third-party services. Leveraging the power of Apache Camel K's camel-kamelets, Knative Eventing can now easily interact with services like AWS SQS, S3, SNS, and DynamoDB streams, significantly reducing the need for custom ContainerSource implementations and simplifying event-driven architectures that span across cloud providers.

• Automated Event Discovery: The evolution of the EventType API addresses the challenge of understanding event schemas. This API allows for the programmatic description of event types, including their attributes and links to data schemas. Crucially, Knative Eventing can now automatically create EventType resources as events flow through a broker, providing an invaluable "head start" for developers in discovering and understanding the shape of events.

• Long-Running Job Offloading with Job Sync: To overcome the limitations of serverless functions with hard processing time limits, Job Sync enables the offloading of long-running event processing to Kubernetes Jobs. This feature allows for event-driven workflows that involve computationally intensive or time-consuming tasks, with the ability to produce new events upon job completion, facilitating complex, scalable event chains.

• Declarative Event Transformation: The new Event Transform feature provides a declarative way to reshape events, particularly JSON-based events, using a JSON expression language. This eliminates the need for developers to write boilerplate code for simple transformations, making it easier to adapt events from disparate systems into a standardized CloudEvents format or to extract specific attributes for filtering and routing.

Technical Deep Dive

▶ Watch: Deep dive into transport encryption via TLS (2:40)

The core of the presentation centered on the technical implementation and usage of these new features, demonstrating a significant leap in Knative Eventing's maturity.

Security Enhancements

Knative Eventing's security enhancements tackle three crucial aspects of event delivery: encryption in transit, sender authentication, and authorization policies.

Transport Encryption via TLS

By default, Knative Eventing previously delivered events over unencrypted HTTP. With the new transport encryption feature, addressables—resources that can receive events, like Brokers or Sinks—can now expose HTTPS endpoints. This ensures that event traffic is encrypted, protecting against eavesdropping if network access is compromised.

The behavior of these endpoints is controlled by the transport-encryption feature flag configuration:

• strict: Addressables only provide an HTTPS endpoint.
• permissive: Addressables provide both HTTP and HTTPS endpoints. Event producers will prefer sending events to the HTTPS endpoint.
• disabled: Falls back to the previous behavior of providing only an HTTP endpoint.

For certificate generation, Knative Eventing leverages cluster-manager under the hood, eliminating the need for external service meshes or complex manual certificate management. Resource statuses now reflect these changes, with the status.addresses field (plural) containing both HTTP and HTTPS addresses, along with certificate details when applicable.

Authentication via OpenID Connect (OIDC)

To verify the identity of event senders, Knative Eventing has integrated OpenID Connect (OIDC). This allows event consumers (addressables) to confirm who sent an event.

• Addressables now expose an autogenerated, unique OIDC audience in their status.address.audience field, which is automatically populated when OIDC authentication is enabled.
• Event producers automatically create a Kubernetes Service Account under the hood, which serves as their identity. When a producer sends an event, it requests an OIDC token for its service account identity and the target's OIDC audience. This token is then attached to the request's authorization header.
• Upon receiving an event, the addressable validates the OIDC token. If the token is valid and for the correct audience, event processing continues. Otherwise, the request is declined with a 401 Unauthorized status code.

The status.serviceAccountName field on event sources now indicates the identity used for sending events, providing transparency and auditability.

Authorization via Event Policies

Building on authentication, authorization allows administrators to restrict which identities can send events to specific resources. This is achieved through a new Custom Resource Definition (CRD) called EventPolicy.

An EventPolicy comprises two main fields:

• spec.to: Specifies which resources are protected by this policy. This can be a direct reference to a resource (e.g., a Broker) or a selector matching multiple resources. If spec.to is empty, the policy applies to all resources in the namespace.
• spec.from: Defines who is allowed to send events to the protected resources. This can be a direct reference to an event source (potentially from another namespace) or a list of service account names (identities). A powerful feature here is the ability to use **prefixes followed by a wildcard (*)** (e.g., my-sa-*) to allow all service accounts matching a pattern, or even all service accounts from a specific namespace.
• filters: An optional section that allows further narrowing down which types of events are permitted, for example, restricting to specific CloudEvent types.

Default Authorization Modes: In scenarios where no EventPolicy is explicitly defined for a resource, Knative Eventing falls back to one of three configurable default authorization modes:

• allow-all: All requests are permitted.
• deny-all: All requests are denied by default, forcing users to create explicit EventPolicy resources.
• allow-same-namespace: Only requests originating from the same Kubernetes namespace as the resource are allowed. This is the default mode and represents a potential breaking change for existing deployments, though it significantly enhances security by default. Users can easily update this default if needed. Requests violating these policies receive a 403 Forbidden status code.

Eventing Integrations

To simplify connecting Knative Eventing to a wider ecosystem of services, new Integration Source and Integration Sync resources have been introduced.

Previously, users relied on limited built-in sources (e.g., APIServerSource, PingSource) or had to develop custom sources using ContainerSource for third-party services. The new integrations leverage Apache Camel K's Kamelets, which provide a vast collection of connectors for various services, including public cloud platforms, messaging systems, and databases.

• Integration Source: Allows Knative Eventing to receive events from external systems. For example, to receive events from AWS SQS, a user simply creates an IntegrationSource resource, provides the SQS configuration options, an AWS authentication secret, and specifies the target sync (e.g., a Broker). The source then automatically pulls events from SQS and forwards them to the specified sync.
• Integration Sync: Enables Knative Eventing to send events to external systems. To send events to AWS SQS, an IntegrationSync is created with SQS configuration and an authentication secret. The sync provides an address to which Knative components can send events, which are then forwarded to SQS.

These native integrations support services like AWS S3, SQS, SNS, and DynamoDB streams. A key benefit is that these integrations are part of the standard Knative Eventing release cycles and inherently support features like TLS out-of-the-box, ensuring secure and reliable connectivity.

Event Discovery

The EventType API has been evolved to address the challenge of event discovery. In complex event-driven systems, understanding what events are produced by various sources and their exact schema is critical but often hindered by poor documentation or the sheer volume of disparate systems.

The EventType CRD allows for a structured description of an event, including:

• A reference to the resource emitting the event.
• A list of attributes, including type, source, and crucially, data-schema which can link to a schema registry (e.g., Confluent, GitHub repo) for detailed schema definitions. Attributes can also include templated values (e.g., id variable in a source value) for describing complex event patterns.

To bootstrap event discovery, Knative Eventing can automatically create EventType resources as events pass through a Broker. While useful for development and getting started, this automatic creation can be turned off for production environments where manual or more controlled EventType definitions might be preferred. The talk also referenced a previous KubeCon NA demo highlighting a Backstage plugin for visualizing these EventType catalogs.

Job Sync

Serverless functions often impose strict time limits (e.g., minutes) on processing duration, which is unsuitable for long-running or computationally intensive tasks. Job Sync provides a solution by enabling the offloading of such processing to Kubernetes Jobs.

When an event arrives at a JobSync, it triggers the creation of a standard Kubernetes Job. The incoming event's data is then mounted onto the Job's file system at a specified path, typically as a JSON file. The Job's container can then read this event data, perform its long-running processing, and is not constrained by typical serverless function timeouts.

A powerful pattern enabled by JobSync is the creation of complex event-driven workflows. Before a Job completes, it can produce a new event, signaling its completion or the result of its processing. This is facilitated by reusing the Sync Binding feature, which injects an address (as the K_SINK environment variable) into a resource like a Pod, Deployment, Job, or StatefulSet. The Job can then send a new event to this K_SINK address, triggering subsequent processing steps in an asynchronous, scalable manner.

Event Transform

The Event Transform feature addresses the need to declaratively reshape events, particularly for integrating systems that may not natively produce CloudEvents (the CNCF standard for event transport). CloudEvents define a standardized way to describe event data and attributes, supporting formats like binary HTTP (attributes in headers, data in body) and structured JSON (entire event as JSON payload). While Knative Eventing supports both, transforming events into a compliant format or extracting specific data often required custom code.

Event Transform aims to eliminate this boilerplate code by providing declarative transformations. It currently supports JSON expression language for transforming JSON events. This expression language, while resembling JSON, allows for unquoted variables to reference parts of the incoming event.

Examples demonstrated:

• Extracting data for CloudEvent attributes: An EventTransform can extract a specific field from the event data (e.g., paymentMethod) and promote it to a CloudEvent attribute. This is useful for filtering and routing events based on rich metadata without processing the entire payload. This can be used with the Broker Reply feature, where a transformed event is sent back to the broker as a new event.
• Shaping non-CloudEvents into CloudEvents: An EventTransform can take an arbitrary JSON payload and declaratively map its fields to the required CloudEvent attributes and data structure, ensuring compliance before forwarding the event to a sink (which can be any HTTP URL, even outside the cluster). This simplifies the onboarding of legacy systems into a Knative Eventing architecture.

Demo / Proof of Concept

▶ Watch: Introducing authorization via new Event Policy CRD (6:25)

While the talk did not feature a live, interactive demonstration in the traditional sense, the speakers provided clear, illustrative examples and YAML configurations for each new feature, effectively serving as conceptual proofs of concept.

For security features, an example was given demonstrating an EventPolicy that allowed ping-source-1 from namespace-1 to send events to a broker in namespace-2, while denying ping-source-2 from namespace-2 (due to the allow-same-namespace default). This clearly showed the authorization logic in action. The OIDC and TLS mechanisms were explained with a focus on their underlying mechanics and how they integrate into the Knative resource model (e.g., status.addresses, status.address.audience).

The Integration Source and Integration Sync capabilities were demonstrated through simplified YAML configurations for connecting to AWS SQS. These examples highlighted the ease of setting up event reception and transmission with minimal configuration, showing how a broker could receive events from SQS or how an event could be sent back to SQS.

For Event Discovery, the concept of the EventType API was explained with a sample CRD, illustrating how attributes and data schemas are described. The automatic creation of EventType resources by the broker was presented as a "head start" for developers. The speakers also referenced a prior KubeCon NA talk that included a demo of a Backstage plugin for visualizing EventType catalogs, implying a functional proof of concept exists.

Job Sync was explained as a pattern, showing how an incoming event triggers a Kubernetes Job, which then consumes the event data mounted to its file system. The concept of using K_SINK for producing a new event upon job completion was detailed, illustrating an event-driven workflow.

Finally, Event Transform was showcased with two practical JSON expression language examples. One demonstrated extracting a paymentMethod from an event's data payload and promoting it to a CloudEvent attribute for filtering purposes. The other illustrated how to transform an arbitrary JSON into a proper CloudEvent structure before forwarding it to a target sync. These examples clearly conveyed the declarative power and utility of the new transformation engine.

These examples, though not live coding or a full end-to-end demo, provided sufficient technical detail and context to understand the practical application and benefits of each new feature.

Defensive Implications

▶ Watch: Practical example of event policy configuration (8:30)

The new features in Knative Eventing significantly bolster its defensive posture, offering critical tools for platform engineers and security teams to build more resilient and secure event-driven architectures.

1. Enhanced Event Delivery Security (TLS, OIDC): The native support for transport encryption via TLS ensures that event data is encrypted in transit between Knative components. This prevents passive eavesdropping and data interception, which is crucial for protecting sensitive information. Coupled with OpenID Connect (OIDC) authentication, defenders can now cryptographically verify the identity of every event producer. This eliminates anonymous event injection, making it much harder for unauthorized actors to introduce malicious or malformed events into the system. Security teams can rely on OIDC tokens to establish a chain of trust for event provenance.

1. Fine-Grained Authorization with Event Policies: The EventPolicy CRD provides a powerful mechanism for fine-grained authorization. Defenders can define explicit rules specifying who (based on service account identity) can send which events (optionally filtered by type) to which resources (brokers, sinks). This aligns with the principle of least privilege, ensuring that only authorized components can interact with specific event streams. The allow-same-namespace default authorization mode is a significant security improvement, preventing cross-namespace event injection by default and forcing explicit policy definitions for broader access. This reduces the attack surface and helps contain potential breaches within a single namespace.

1. Secure Third-Party Integrations: The Integration Source and Integration Sync features, powered by Apache Camel K, simplify connecting to external services like AWS SQS. Crucially, these native integrations are designed with security in mind, offering TLS support out-of-the-box. This means defenders no longer need to worry about securing custom ContainerSource implementations for external connectivity, reducing the likelihood of misconfigurations or vulnerabilities introduced through bespoke code. Centralizing these integrations also allows for consistent application of security best practices.

1. Improved Event Visibility and Auditability (EventType API): The EventType API significantly enhances visibility into the types and schemas of events flowing through the system. For security teams, this improved discoverability is invaluable for several reasons:

• Incident Response: Quickly understanding the expected structure of events helps in analyzing logs during an incident, identifying anomalous event types or malformed payloads that might indicate an attack.
• Policy Enforcement: Knowing event schemas allows for more precise filtering and validation rules to be implemented, both within EventPolicy and at the consumer level.
• Auditing: A clear catalog of event types supports comprehensive auditing of event flows and data transformations.

The automatic creation of EventType resources, while a development convenience, should be carefully managed in production environments to maintain a curated and trusted event catalog.

1. Robust Long-Running Processing (Job Sync): Job Sync allows for the secure offloading of long-running, potentially resource-intensive, or untrusted processing tasks to isolated Kubernetes Jobs. This prevents such tasks from tying up or compromising critical event-handling components (like Knative Services). By running these jobs in dedicated pods, defenders can apply specific resource quotas, network policies, and security contexts, isolating them from other parts of the eventing system and minimizing blast radius in case of a compromise.

1. Declarative Event Transformation for Security Policy: Event Transform allows for declarative reshaping of events. This can be leveraged defensively to enforce strict schema compliance or to redact sensitive information before events are forwarded to downstream systems. By transforming events into a standardized CloudEvents format, it becomes easier to apply consistent security policies, filtering, and validation across the entire event-driven architecture, reducing the complexity of securing disparate event formats.

In summary, Knative Eventing's latest updates provide a powerful toolkit for building inherently more secure event-driven applications on Kubernetes. By embracing native security, streamlining integrations, enhancing discoverability, and improving operational robustness, these features empower defenders to proactively mitigate risks and establish a strong security foundation.

Key Takeaways

• Security is Now First-Class: Knative Eventing significantly enhances its security posture with native TLS transport encryption, OpenID Connect (OIDC) authentication, and Event Policy authorization, moving from an insecure-by-default model to a secure-by-default approach for event delivery.
• Simplified Integrations with External Services: The new Integration Source and Integration Sync leverage Apache Camel K to provide native, secure, and streamlined connectivity to popular third-party services like AWS SQS, S3, SNS, and DynamoDB streams, reducing custom code overhead.
• Automated Event Discovery for Developers: The evolved EventType API allows for programmatic description of event schemas and can automatically create EventType resources as events flow through a broker, greatly improving developer experience and understanding of event structures.
• Support for Long-Running Event Processing: Job Sync enables offloading time-consuming event processing to Kubernetes Jobs, overcoming serverless function duration limits and facilitating complex, scalable event-driven workflows that can re-emit events upon completion.
• Declarative Event Transformations: The Event Transform feature provides a declarative JSON expression language to reshape events, allowing for easy adaptation of non-CloudEvents into standard formats or extraction of key attributes without writing boilerplate code.
• Improved Multi-Tenancy and Defensive Capabilities: The new security features, especially EventPolicy with its allow-same-namespace default, provide foundational elements for building more secure multi-tenant eventing platforms and offer critical tools for security professionals to enforce least privilege and protect event streams.

About the Speaker(s)

Pierangelo Di Pilato is a Software Engineer at Red Hat. He also serves as the working group lead for Knative Eventing, indicating his deep involvement and leadership in the project's direction and development. His expertise lies in serverless topics and event-driven architectures within the Kubernetes ecosystem.

Christoph Stäbler is also a Software Engineer at Red Hat, focusing on serverless technologies. He is a maintainer of several Knative Eventing projects, demonstrating his hands-on contribution to the codebase and his commitment to the project's ongoing evolution and stability.