Questo contenuto non è disponibile nella lingua selezionata.

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

Knative Eventing authorization is governed by two key mechanisms. The EventPolicy custom resource defines explicit rules for event delivery, and the default-authorization-mode feature flag applies whenever no EventPolicy is associated with a resource.

The supported authorization modes are as follows:

Expand
Authorization modeDescription

allow-all

All incoming event requests are permitted without restriction.

deny-all

All incoming event requests are denied. To enable event delivery, an EventPolicy must explicitly authorize the requests.

allow-same-namespace

(Default) Only requests from subjects within the same namespace are allowed.

To configure the default authorization mode via 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"
Copy to Clipboard Toggle word wrap

12.2. EventPolicy resource overview

The EventPolicy resource defines rules for event delivery. It specifies which entities like service accounts or event sources are allowed to send events, which consumers may receive events, and optionally, additional criteria that CloudEvents must match to be accepted.

An EventPolicy is structured with three primary sections as follows:

Expand

.spec.to

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

.spec.from

Defines which sources or subjects are authorized to send events to the targets.

.spec.filters

(Optional) Specifies advanced filtering conditions that must be satisfied by the CloudEvent itself before it is allowed.

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
Copy to Clipboard Toggle word wrap

12.3. Defining targets in an EventPolicy

The .spec.to section determines the consumers to which an EventPolicy applies. If the field is omitted, the EventPolicy applies to all resources within the namespace. You can specify multiple targets in this section to broaden the scope of the policy. There are two main ways to define targets.

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
Copy to Clipboard Toggle word wrap

12.3.2. Label-based resource selection

The to.selector method uses label selectors to match multiple 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
Copy to Clipboard Toggle word wrap

12.4. Defining authorized senders in an EventPolicy

The .spec.from section specifies the entities allowed to send events to the resources listed in .spec.to. This section can reference specific event sources or subjects service accounts, and it supports wildcard matching for broader coverage. There are two main ways to define senders.

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
Copy to Clipboard Toggle word wrap

12.4.2. Subject based authorization

The from.sub method specifies subjects, such as service accounts, that are allowed to send events. Wildcard patterns with * are used to authorize multiple accounts matching a pattern. For example, an EventPolicy may authorize a single trusted service account and also allow all accounts beginning with other- in the same namespace.

Example of from.sub method

from:
  - sub: system:serviceaccount:default:trusted-app
  - sub: "system:serviceaccount:default:other-*"
Copy to Clipboard Toggle word wrap

12.5. Advanced CloudEvent filtering criteria

The .spec.filters method is optional but provides advanced criteria for event delivery. These filters allow you to restrict which events are permitted based not only on the source but also on the properties of the CloudEvent itself.

For example, you can specify filters that only allow events of type com.github.push, or events that match a CloudEvents SQL (CESQL) expression for particular 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
Copy to Clipboard Toggle word wrap

Note

Filters are applied in addition to the .spec.from method. This means that an event must satisfy both the sender authorization and the filter criteria before it is delivered.

12.6. EventPolicy status and application

The status of an EventPolicy provides runtime information about which sources have been resolved and 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"
Copy to Clipboard Toggle word wrap

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

status:
  policies:
    - name: my-event-policy
      apiVersion: v1alpha1
  conditions:
    - type: Ready
      status: "True"
    - type: EventPoliciesReady
      status: "True"
Copy to Clipboard Toggle word wrap

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

If an incoming request fails to satisfy any applicable EventPolicy, it will be rejected with an HTTP 403 Forbidden status code. If multiple EventPolicies apply to a resource, an event is accepted as long as it matches at least one of them. This ensures that unauthorized event deliveries are blocked at the system level.

When multiple EventPolicies apply to the same resource, the system evaluates them in parallel. An event is accepted if it matches at least one applicable EventPolicy. This approach allows flexibility, as valid events are not rejected even under strict authorization, so long as they satisfy the requirements of at least one policy.

12.7. Applying an EventPolicy

This section describes the end-to-end steps for applying an EventPolicy to secure event delivery. In the following reference example, a Broker in namespace-1 is configured to only accept events from a PingSource running in a different namespace namespace-2.

Prerequisites

  • The OpenShift Serverless Operator and Knative Eventing are installed 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 per 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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

    At this stage, because OIDC is disabled and no EventPolicy is applied, 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"}}}}'
    Copy to Clipboard Toggle word wrap
  4. Once OIDC is enabled, 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
    Copy to Clipboard Toggle word wrap

Verification

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

    $ oc -n namespace-1 get broker broker -o yaml
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  3. Delete the EventPolicy by executing the following command:

    $ oc -n namespace-1 delete eventpolicy event-policy
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat