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-oidcfeature.
Procedure
Create two namespaces, deploy a Broker in
namespace-1, and configure onePingSourcein 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-2as 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 yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow View logs from the event-display service to confirm only
pingsource-2events 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-displayCopy 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-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Check the Broker status to confirm it has returned to the default
allow-same-namespacemode by executing the following command:oc -n namespace-1 get broker broker -o yaml
$ oc -n namespace-1 get broker broker -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow View the event-display service logs to confirm that only
pingsource-1events 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-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow