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.
You must enable the transport-encryption
feature flag along with authentication-oidc
to ensure secure and authenticated event delivery.
12.1. Default authorization mode Copia collegamentoCollegamento copiato negli appunti!
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:
Authorization mode | Description |
---|---|
| All incoming event requests are permitted without restriction. |
| All incoming event requests are denied. To enable event delivery, an EventPolicy must explicitly authorize the requests. |
| (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:
12.2. EventPolicy resource overview Copia collegamentoCollegamento copiato negli appunti!
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:
| Defines the resources such as Brokers or Channels that the EventPolicy applies to. |
| Defines which sources or subjects are authorized to send events to the targets. |
| (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:
12.3. Defining targets in an EventPolicy Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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
to:
- ref:
apiVersion: eventing.knative.dev/v1
kind: Broker
name: my-broker
12.3.2. Label-based resource selection Copia collegamentoCollegamento copiato negli appunti!
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
12.4. Defining authorized senders in an EventPolicy Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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
12.4.2. Subject based authorization Copia collegamentoCollegamento copiato negli appunti!
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-*"
from:
- sub: system:serviceaccount:default:trusted-app
- sub: "system:serviceaccount:default:other-*"
12.5. Advanced CloudEvent filtering criteria Copia collegamentoCollegamento copiato negli appunti!
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
filters:
- cesql: "type IN ('order.created', 'order.updated', 'order.canceled')"
- exact:
type: com.github.push
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 Copia collegamentoCollegamento copiato negli appunti!
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:
Event consumers, such as Brokers, reflect which EventPolicies apply to them in their status.
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 Copia collegamentoCollegamento copiato negli appunti!
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
Create two namespaces, deploy a Broker in
namespace-1
, and configure onePingSource
in each namespace as per shown in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow At this stage, because OIDC is disabled and no EventPolicy is applied, the event-display service shows events from both PingSources.
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"}}}}'
$ oc -n knative-eventing patch KnativeEventing knative-eventing \ --type merge \ -p '{"spec":{"config":{"features":{"authentication-oidc":"enabled"}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Once OIDC is enabled, create an EventPolicy that authorizes only the PingSource from
namespace-2
as shown in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Verify the EventPolicy to check the Broker status by executing the following command:
oc -n namespace-1 get broker broker -o yaml
$ oc -n namespace-1 get broker broker -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ oc -n namespace-1 logs -f -l app=event-display
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Delete the EventPolicy by executing the following command:
oc -n namespace-1 delete eventpolicy event-policy
$ oc -n namespace-1 delete eventpolicy event-policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ oc -n namespace-1 get broker broker -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ oc -n namespace-1 logs -f -l app=event-display
Copy to Clipboard Copied! Toggle word wrap Toggle overflow