Este conteúdo não está disponível no idioma selecionado.
Chapter 12. Authorization and EventPolicy in Knative Eventing
Knative Eventing provides a way to secure event delivery and prevent unauthorized access. Event-driven systems often involve many producers and consumers. Without proper authorization controls, unintended or malicious event flows can compromise the system.
12.1. EventPolicy for securing event delivery Copiar o linkLink copiado para a área de transferência!
To achieve fine-grained access control, Knative Eventing introduces the EventPolicy custom resource. This resource allows administrators and developers to define which entities can send events to specific consumers within a namespace.
You can apply EventPolicies to ensure that only trusted event sources or service accounts can send data to selected event consumers. This approach improves the overall security of your event-driven architecture.
You must enable the transport-encryption feature flag along with authentication-oidc to ensure secure and authenticated event delivery.
12.2. Default authorization mode Copiar o linkLink copiado para a área de transferência!
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.3. EventPolicy resource overview Copiar o linkLink copiado para a área de transferência!
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.4. Defining targets in an EventPolicy Copiar o linkLink copiado para a área de transferência!
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.4.1. Specific resource reference Copiar o linkLink copiado para a área de transferência!
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.
The following example displayes to.ref method:
to:
- ref:
apiVersion: eventing.knative.dev/v1
kind: Broker
name: my-broker
12.4.2. Label-based resource selection Copiar o linkLink copiado para a área de transferência!
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.
The following example displayes to.selector method:
to:
- selector:
apiVersion: eventing.knative.dev/v1
kind: Broker
matchLabels:
app: special-app
12.5. Defining authorized senders in an EventPolicy Copiar o linkLink copiado para a área de transferência!
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.5.1. Event source by name Copiar o linkLink copiado para a área de transferência!
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.
The following example displayes from.ref method:
from:
- ref:
apiVersion: sources.knative.dev/v1
kind: PingSource
name: my-source
namespace: another-namespace
12.5.2. Subject based authorization Copiar o linkLink copiado para a área de transferência!
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.
The following example displayes from.sub method:
from:
- sub: system:serviceaccount:default:trusted-app
- sub: "system:serviceaccount:default:other-*"
12.6. Advanced CloudEvent filtering criteria Copiar o linkLink copiado para a área de transferência!
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.
The following example displayes 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.7. EventPolicy status and application Copiar o linkLink copiado para a área de transferência!
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.8. Applying an EventPolicy Copiar o linkLink copiado para a área de transferência!
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 running 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 running 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 running the following command:$ oc -n namespace-1 logs -f -l app=event-displayDelete the
EventPolicyby running 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 running 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 running the following command:$ oc -n namespace-1 logs -f -l app=event-display