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.
You must enable the transport-encryption feature flag along with authentication-oidc to ensure secure and authenticated event delivery.
12.1. Default authorization mode Link kopierenLink in die Zwischenablage kopiert!
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:
| Authorization mode | Description |
|---|---|
|
| The system permits all incoming event requests without restriction. |
|
|
The system denies all incoming event requests. To enable event delivery, you must configure an |
|
| (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 Link kopierenLink in die Zwischenablage kopiert!
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:
|
| Defines the resources such as Brokers or Channels that the EventPolicy applies to. |
|
| Specify which sources or subjects can send events to the targets. |
|
|
(Optional) Specify advanced filtering conditions that the |
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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-oidcfeature.
Procedure
Create two namespaces, deploy a Broker in
namespace-1, and configure onePingSourcein 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-1Create 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-displayAt this stage, OIDC remains disabled and no
EventPolicyexists, so the event-display service shows events from bothPingSources.Enable OIDC in Knative Eventing and create an
EventPolicyby executing the following example command:$ oc -n knative-eventing patch KnativeEventing knative-eventing \ --type merge \ -p '{"spec":{"config":{"features":{"authentication-oidc":"enabled"}}}}'After you enable OIDC, create an
EventPolicythat authorizes only thePingSourcefromnamespace-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
Verify the
EventPolicyto check the Broker status by executing the following command:$ oc -n namespace-1 get broker broker -o yamlView 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-displayDelete the
EventPolicyby executing the following command:$ oc -n namespace-1 delete eventpolicy event-policyCheck 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 yamlView 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