Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 12. Authorization and EventPolicy in Knative Eventing


Knative Eventing provides a mechanism to secure event delivery to prevent unauthorized access. Event-driven systems often rely on multiple producers and consumers of events, and without proper authorization controls, malicious or unintended event flows could compromise the system.

To achieve fine-grained access control, Knative Eventing introduces the EventPolicy custom resource. This resource allows administrators and developers to define which entities are authorized to send events to specific consumers within a namespace. By applying EventPolicies, you can ensure that only trusted event sources or service accounts are able to send data to selected event consumers and this improves the overall security posture of their event-driven architecture.

Note

You must enable the transport-encryption feature flag along with authentication-oidc to ensure secure and authenticated event delivery.

12.1. Default authorization mode

Two key mechanisms govern Knative Eventing authorization. The EventPolicy custom resource defines explicit rules for event delivery. The default-authorization-mode feature flag applies when a resource does not reference an EventPolicy.

The supported authorization modes are as follows:

Expand
Authorization modeDescription

allow-all

The system permits all incoming event requests without restriction.

deny-all

The system denies all incoming event requests. To enable event delivery, you must configure an EventPolicy that explicitly allows the requests.

allow-same-namespace

(Default) The system allows only requests from subjects within the same namespace.

To configure the default authorization mode from the OpenShift Serverless Operator, you can edit the KnativeEventing custom resource as shown in the following example:

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  config:
    features:
      authentication-oidc: "enabled"
      default-authorization-mode: "deny-all"

12.2. EventPolicy resource overview

The EventPolicy resource defines rules for event delivery. It specifies that entities, such as service accounts or event sources, can send events and which consumers can receive them. You can also define additional criteria that CloudEvents must match before the system accepts them.

An EventPolicy includes the following three primary sections:

Expand

.spec.to

Defines the resources such as Brokers or Channels that the EventPolicy applies to.

.spec.from

Specify which sources or subjects can send events to the targets.

.spec.filters

(Optional) Specify advanced filtering conditions that the CloudEvent must satisfy before the system accepts it.

The example of an EventPolicy is as follows:

apiVersion: eventing.knative.dev/v1alpha1
kind: EventPolicy
metadata:
  name: my-event-policy
  namespace: default
spec:
  to:
    - ref:
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        name: my-broker
    - selector:
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        matchLabels:
          app: special-app
  from:
    - ref:
        apiVersion: sources.knative.dev/v1
        kind: PingSource
        name: my-source
        namespace: another-namespace
    - sub: system:serviceaccount:default:trusted-app
    - sub: "system:serviceaccount:default:other-*"
  filters:
    - cesql: "type IN ('order.created', 'order.updated', 'order.canceled')"
    - exact:
        type: com.github.push

12.3. Defining targets in an EventPolicy

The .spec.to field determines that consumers an EventPolicy applies to. If you do not specify this field, the EventPolicy applies to all resources in the namespace. You can specify many targets to broaden the scope of the policy. You can define targets in two main ways.

12.3.1. Specific resource reference

The to.ref method directly references a specific resource by name. For example, referencing a Broker named my-broker applies the EventPolicy only to that specific Broker. This method is most appropriate when you want to protect or restrict access to a well-defined, individual resource.

Example of to.ref method

to:
  - ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: my-broker

12.3.2. Label-based resource selection

The to.selector method uses label selectors to match many resources of a specific type. For example, specifying a label selector with app: special-app applies the EventPolicy to all Brokers that share that label. This method is suitable when you want the same authorization rules applied across a group of similar resources.

Example of to.selector method

to:
  - selector:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      matchLabels:
        app: special-app

12.4. Defining authorized senders in an EventPolicy

The .spec.from field specifies the entities that can send events to the resources listed in .spec.to. You can reference specific event sources or subject service accounts. The field also supports wildcard matching for broader coverage. You can define senders in two main ways.

12.4.1. Event source by name

The from.ref method directly references an event source resource. For example, referencing a PingSource in a different namespace ensures that only that specific source can deliver events to the defined targets.

Example of from.ref method

from:
  - ref:
      apiVersion: sources.knative.dev/v1
      kind: PingSource
      name: my-source
      namespace: another-namespace

12.4.2. Subject based authorization

The from.sub field specifies subjects, such as service accounts, which can send events. You can use wildcard patterns with * to allow many accounts that match a pattern. For example, an EventPolicy can allow one trusted service account and allow all accounts that begin with other- in the same namespace.

Example of from.sub method

from:
  - sub: system:serviceaccount:default:trusted-app
  - sub: "system:serviceaccount:default:other-*"

12.5. Advanced CloudEvent filtering criteria

The .spec.filters method is optional and provides advanced criteria for event delivery. These filters restrict events based not only on the source but also on the properties of the CloudEvent.

For example, you can configure filters to allow only events of type com.github.push. You can also configure filters that match a CloudEvents SQL (CESQL) expression for event types such as order.created, order.updated, or order.canceled.

Example of spec.filters method

filters:
  - cesql: "type IN ('order.created', 'order.updated', 'order.canceled')"
  - exact:
      type: com.github.push

Note

Filters apply in addition to the .spec.from method. An event must satisfy both the sender authorization and the filter criteria before the system delivers it.

12.6. EventPolicy status and application

The status of an EventPolicy shows runtime information about resolved sources and indicates whether the policy is active and ready, as shown in the following example:

status:
  from:
    - system:serviceaccount:default:trusted-app
    - "system:serviceaccount:default:other-*"
  conditions:
    - type: Ready
      status: "True"
    - type: SubjectsResolved
      status: "True"

Event consumers, such as Brokers, reflect that EventPolicies apply to them in their status.

status:
  policies:
    - name: my-event-policy
      apiVersion: v1alpha1
  conditions:
    - type: Ready
      status: "True"
    - type: EventPoliciesReady
      status: "True"

These conditions indicate whether EventPolicies are ready and have been successfully applied to the resource.

If an incoming request does not satisfy any applicable EventPolicy, the system returns an HTTP 403 Forbidden status code. When many EventPolicies apply to a resource, the system evaluates them in parallel. The system accepts an event if it matches at least one policy. This behavior blocks unauthorized event deliveries while still allowing valid events that satisfy at least one policy.

12.7. Applying an EventPolicy

You can apply an EventPolicy to secure event delivery by following these end-to-end steps. The following example configures a Broker in namespace-1 to accept events only from a PingSource running in namespace-2.

Prerequisites

  • You have installed the OpenShift Serverless Operator and Knative Eventing on your OpenShift Container Platform cluster.
  • You have enabled the authentication-oidc feature.

Procedure

  1. Create two namespaces, deploy a Broker in namespace-1, and configure one PingSource in each namespace as shown in the following example:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: namespace-1
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: namespace-2
    ---
    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      name: broker
      namespace: namespace-1
    ---
    # PingSource in namespace-1
    apiVersion: sources.knative.dev/v1
    kind: PingSource
    metadata:
      name: pingsource-1
      namespace: namespace-1
    spec:
      data: '{"message": "Hi from pingsource-1 from namespace-1"}'
      schedule: '*/1 * * * *'
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: broker
          namespace: namespace-1
    ---
    # PingSource in namespace-2
    apiVersion: sources.knative.dev/v1
    kind: PingSource
    metadata:
      name: pingsource-2
      namespace: namespace-2
    spec:
      data: '{"message": "Hi from pingsource-2 from namespace-2"}'
      schedule: '*/1 * * * *'
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: broker
          namespace: namespace-1
  2. Create an event-display service to show incoming events and add a Trigger to connect it to the Broker as shown in the following example:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: event-display
      namespace: namespace-1
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: event-display
      template:
        metadata:
          labels:
            app: event-display
        spec:
          containers:
            - name: event-display
              image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
              ports:
              - containerPort: 8080
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: event-display
      namespace: namespace-1
    spec:
      selector:
        app: event-display
      ports:
        - name: http
          port: 80
          targetPort: 8080
    ---
    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: trigger
      namespace: namespace-1
    spec:
      broker: broker
      subscriber:
        ref:
          apiVersion: v1
          kind: Service
          name: event-display

    At this stage, OIDC remains disabled and no EventPolicy exists, so the event-display service shows events from both PingSources.

  3. Enable OIDC in Knative Eventing and create an EventPolicy by executing the following example command:

    $ oc -n knative-eventing patch KnativeEventing knative-eventing \
      --type merge \
      -p '{"spec":{"config":{"features":{"authentication-oidc":"enabled"}}}}'
  4. After you enable OIDC, create an EventPolicy that authorizes only the PingSource from namespace-2, as shown in the following example:

    apiVersion: eventing.knative.dev/v1alpha1
    kind: EventPolicy
    metadata:
      name: event-policy
      namespace: namespace-1
    spec:
      to:
        - ref:
            apiVersion: eventing.knative.dev/v1
            kind: Broker
            name: broker
      from:
        - ref:
            apiVersion: sources.knative.dev/v1
            kind: PingSource
            name: pingsource-2
            namespace: namespace-2

Verification

  1. Verify the EventPolicy to check the Broker status by executing the following command:

    $ oc -n namespace-1 get broker broker -o yaml
  2. View logs from the event-display service to confirm only pingsource-2 events arrive by executing the following command:

    $ oc -n namespace-1 logs -f -l app=event-display
  3. Delete the EventPolicy by executing the following command:

    $ oc -n namespace-1 delete eventpolicy event-policy
  4. Check the Broker status to confirm it has returned to the default allow-same-namespace mode by executing the following command:

    $ oc -n namespace-1 get broker broker -o yaml
  5. View the event-display service logs to confirm that only pingsource-1 events from the same namespace appear by executing the following command:

    $ oc -n namespace-1 logs -f -l app=event-display
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red Hat
Nach oben