From fa1308b8bcac1c721260ac591427b4beeb9a9e79 Mon Sep 17 00:00:00 2001 From: Pierangelo Di Pilato Date: Mon, 12 Jun 2023 11:45:01 +0200 Subject: [PATCH 1/4] SRVKE-1419: Document Eventing mTLS with Service Mesh Signed-off-by: Pierangelo Di Pilato --- antora.yml | 5 + modules/ROOT/nav.adoc | 5 + ...eventing-service-mesh-containersource.adoc | 123 ++++++ .../eventing-service-mesh-setup.adoc | 382 ++++++++++++++++++ .../eventing-service-mesh-sinkbinding.adoc | 165 ++++++++ 5 files changed, 680 insertions(+) create mode 100644 modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-containersource.adoc create mode 100644 modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc create mode 100644 modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-sinkbinding.adoc diff --git a/antora.yml b/antora.yml index e66ff653..0e2d5dba 100644 --- a/antora.yml +++ b/antora.yml @@ -6,6 +6,11 @@ nav: start_ROOT: 'ROOT:index.adoc' asciidoc: attributes: + smproductshortname: Service Mesh + smproductname: OpenShift Service Mesh + product-title: OpenShift + serverlessoperatorname: OpenShift Serverless Operator + serverlessproductname: OpenShift Serverless product_name: OpenShift Serverless Logic context: OpenShift Serverless Logic kogito_version_redhat: 1.35.0.Final-redhat-00003 diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index a8fdc603..68c6a652 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -1,4 +1,9 @@ * xref:index.adoc[Overview] +* Serverless Eventing +** Using Eventing with OpenShift Service Mesh +*** xref:serverless-eventing:service-mesh/eventing-service-mesh-setup.adoc[Setup Eventing with OpenShift Service Mesh] +*** xref:serverless-eventing:service-mesh/eventing-service-mesh-containersource.adoc[Using ContainerSource with OpenShift Service Mesh] +*** xref:serverless-eventing:service-mesh/eventing-service-mesh-sinkbinding.adoc[Using SinkBinding with OpenShift Service Mesh] * Serverless Logic ** xref:serverless-logic:about.adoc[About OpenShift Serverless Logic] ** User Guides diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-containersource.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-containersource.adoc new file mode 100644 index 00000000..a5673f62 --- /dev/null +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-containersource.adoc @@ -0,0 +1,123 @@ += Using ContainerSource with {SMProductName} +:compat-mode!: +// Metadata: +:description: Using ContainerSource with {SMProductName} + +.Prerequisites + +* You have followed the setup {SMProductShortName} with {ServerlessProductName} procedure + +.Procedure + +. Create a `Service` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: serving.knative.dev/v1 +kind: Service +metadata: + name: event-display + namespace: <1> +spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: "true" <2> + sidecar.istio.io/rewriteAppHTTPProbers: "true" + spec: + containers: + - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the Knative service pods. + +. Apply the `Service` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `ContainerSource` in a namespace that is member of the `ServiceMeshMemberRoll` and sink set to the `event-display`: ++ +[source,yaml] +---- +apiVersion: sources.knative.dev/v1 +kind: ContainerSource +metadata: + name: test-heartbeats + namespace: <1> +spec: + template: + metadata: <2> + annotations: + sidecar.istio.io/inject": "true" + sidecar.istio.io/rewriteAppHTTPProbers: "true" + spec: + containers: + # This corresponds to a heartbeats image URI that you have built and published + - image: gcr.io/knative-releases/knative.dev/eventing/cmd/heartbeats + name: heartbeats + args: + - --period=1s + env: + - name: POD_NAME + value: "example-pod" + - name: POD_NAMESPACE + value: "event-test" + sink: + ref: + apiVersion: serving.knative.dev/v1 + kind: Service + name: event-display-service +---- +<1> A namespace that is part of the `ServiceMeshMemberRoll`. +<2> Enables {SMProductShortName} integration with a `ContainerSource` + +. Apply the `ContainerSource` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Verification + +You can verify that the events were sent to the Knative event sink by looking at the message dumper function logs. + +. Enter the command: ++ +[source,terminal] +---- +$ oc get pods +---- + +. Enter the command: ++ +[source,terminal] +---- +$ oc logs $(oc get pod -o name | grep event-display) -c user-container +---- ++ +.Example output +[source,terminal] +---- +☁️ cloudevents.Event +Validation: valid +Context Attributes, + specversion: 1.0 + type: dev.knative.eventing.samples.heartbeat + source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod + id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 + time: 2019-10-18T15:23:20.809775386Z + contenttype: application/json +Extensions, + beats: true + heart: yes + the: 42 +Data, + { + "id": 1, + "label": "" + } +---- diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc new file mode 100644 index 00000000..fd0801d2 --- /dev/null +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc @@ -0,0 +1,382 @@ += Setup Eventing with {SMProductName} +:compat-mode!: +// Metadata: +:description: Setup Eventing with {SMProductName} + +// TODO + +.Prerequisites + +* You have access to an {product-title} account with cluster administrator access. + +* You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {product-title}. + +* Install the {SMProductName} Operator and create a `ServiceMeshControlPlane` resource in the `istio-system` namespace. If you want to use mTLS functionality, you must also set the `spec.security.dataPlane.mtls` field for the `ServiceMeshControlPlane` resource to `true`. ++ +[IMPORTANT] +==== +Using {ServerlessProductName} with {SMProductShortName} is only supported with {SMProductName} version 2.0.5 or later. +==== + +* Install the {ServerlessOperatorName}. + +* Install the OpenShift CLI (`oc`). + +.Procedure + +. Add the namespaces that you would like to integrate with {SMProductShortName} to the `ServiceMeshMemberRoll` object as members: ++ +[source,yaml] +---- +apiVersion: maistra.io/v1 +kind: ServiceMeshMemberRoll +metadata: + name: default + namespace: istio-system +spec: + members: <1> + - knative-serving + - knative-eventing + - +---- +<1> A list of namespaces to be integrated with {SMProductShortName}. ++ +[IMPORTANT] +==== +This list of namespaces must include the `knative-serving` namespace. +==== + +. Apply the `ServiceMeshMemberRoll` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create the necessary gateways so that {SMProductShortName} can accept traffic: ++ +.Example `knative-local-gateway` object using HTTP +[source,yaml] +---- +apiVersion: networking.istio.io/v1alpha3 +kind: Gateway +metadata: + name: knative-ingress-gateway + namespace: knative-serving +spec: + selector: + istio: ingressgateway + servers: + - port: + number: 443 + name: https + protocol: HTTPS + hosts: + - "*" + tls: + mode: SIMPLE + credentialName: <1> +--- +apiVersion: networking.istio.io/v1alpha3 +kind: Gateway +metadata: + name: knative-local-gateway + namespace: knative-serving +spec: + selector: + istio: ingressgateway + servers: + - port: + number: 8081 + name: http + protocol: HTTP <2> + hosts: + - "*" +--- +apiVersion: v1 +kind: Service +metadata: + name: knative-local-gateway + namespace: istio-system + labels: + experimental.istio.io/disable-gateway-port-translation: "true" +spec: + type: ClusterIP + selector: + istio: ingressgateway + ports: + - name: http2 + port: 80 + targetPort: 8081 +---- +<1> Add the name of the secret that contains the wildcard certificate. +<2> The `knative-local-gateway` serves HTTP traffic. Using HTTP means that traffic coming from outside of {SMProductShortName}, but using an internal hostname, such as `example.default.svc.cluster.local`, is not encrypted. You can set up encryption for this path by creating another wildcard certificate and an additional gateway that uses a different `protocol` spec. ++ +.Example `knative-local-gateway` object using HTTPS +[source,yaml] +---- +apiVersion: networking.istio.io/v1alpha3 +kind: Gateway +metadata: + name: knative-local-gateway + namespace: knative-serving +spec: + selector: + istio: ingressgateway + servers: + - port: + number: 443 + name: https + protocol: HTTPS + hosts: + - "*" + tls: + mode: SIMPLE + credentialName: +---- + +. Apply the `Gateway` resources: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Install Knative Serving by creating the following `KnativeServing` custom resource definition (CRD), which also enables the Istio integration: ++ +[source,yaml] +---- +apiVersion: operator.knative.dev/v1beta1 +kind: KnativeServing +metadata: + name: knative-serving + namespace: knative-serving +spec: + ingress: + istio: + enabled: true <1> + deployments: <2> + - name: activator + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: autoscaler + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" +---- +<1> Enables Istio integration. +<2> Enables sidecar injection for Knative Serving data plane pods. + +. Apply the `KnativeServing` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Install Knative Eventing by creating the following `KnativeEventing` custom resource definition (CRD), which also enables the Istio integration: ++ +[source,yaml] +---- +apiVersion: operator.knative.dev/v1beta1 +kind: KnativeEventing +metadata: + name: knative-eventing + namespace: knative-eventing +spec: + config: + features: + istio: enabled <1> + workloads: <2> + - name: pingsource-mt-adapter + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: imc-dispatcher + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: mt-broker-ingress + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: mt-broker-filter + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" +---- +<1> Enables Eventing istio controller to create a `DestinationRule` for each InMemoryChannel or KafkaChannel service. +<2> Enables sidecar injection for Knative Eventing pods. + +. Apply the `KnativeEventing` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Install Knative Kafka by creating the following `KnativeKafka` custom resource definition (CRD), which also enables the Istio integration: ++ +[source,yaml] +---- +apiVersion: operator.serverless.openshift.io/v1alpha1 +kind: KnativeKafka +metadata: + name: knative-kafka + namespace: knative-eventing +spec: + channel: + enabled: true + bootstrapServers: <1> + source: + enabled: true + broker: + enabled: true + defaultConfig: + bootstrapServers: <1> + numPartitions: + replicationFactor: + sink: + enabled: true + workloads: <2> + - name: kafka-controller + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: kafka-broker-receiver + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: kafka-broker-dispatcher + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: kafka-channel-receiver + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: kafka-channel-dispatcher + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: kafka-source-dispatcher + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" + - name: kafka-sink-receiver + annotations: + "sidecar.istio.io/inject": "true" + "sidecar.istio.io/rewriteAppHTTPProbers": "true" +---- +<1> The Apache Kafka cluster URL, for example: `my-cluster-kafka-bootstrap.kafka:9092`. +<2> Enables sidecar injection for Knative Kafka pods. + +. Apply the `KnativeKafka` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Install `ServiceEntry` to make {SMProductName} aware of the communication between `KnativeKafka` components and an Apache Kafka cluster: ++ +[source,yaml] +---- +apiVersion: networking.istio.io/v1alpha3 +kind: ServiceEntry +metadata: + name: kafka-cluster + namespace: knative-eventing +spec: + hosts: <1> + - + exportTo: + - "." + ports: <2> + - number: 9092 + name: tcp-plain + protocol: TCP + - number: 9093 + name: tcp-tls + protocol: TCP + - number: 9094 + name: tcp-sasl-tls + protocol: TCP + - number: 9095 + name: tcp-sasl-tls + protocol: TCP + - number: 9096 + name: tcp-tls + protocol: TCP + location: MESH_EXTERNAL + resolution: NONE +---- +<1> The list of Apache Kafka cluster hosts, for example: `my-cluster-kafka-bootstrap.kafka`. +<2> Apache Kafka cluster listeners ports. + ++ +[NOTE] +==== +The listed ports in `spec.ports` are example TPC ports and depend on how the Apache Kafka cluster is configured. +==== + +. Apply the `ServiceEntry` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Verification + +. Create a Knative Service that has sidecar injection enabled and uses a pass-through route: ++ +[source,yaml] +---- +apiVersion: serving.knative.dev/v1 +kind: Service +metadata: + name: + namespace: <1> + annotations: + serving.knative.openshift.io/enablePassthrough: "true" <2> +spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: "true" <3> + sidecar.istio.io/rewriteAppHTTPProbers: "true" + spec: + containers: + - image: +---- +<1> A namespace that is part of the Service Mesh member roll. +<2> Instructs Knative Serving to generate an {product-title} pass-through enabled route, so that the certificates you have generated are served through the ingress gateway directly. +<3> Injects {SMProductShortName} sidecars into the Knative service pods. + +. Apply the `Service` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Access your serverless application by using a secure connection that is now trusted by the CA: ++ +[source,terminal] +---- +$ curl --cacert root.crt +---- ++ +.Example command +[source,terminal] +---- +$ curl --cacert root.crt https://hello-default.apps.openshift.example.com +---- ++ +.Example output +[source,terminal] +---- +Hello Openshift! +---- diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-sinkbinding.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-sinkbinding.adoc new file mode 100644 index 00000000..59d42793 --- /dev/null +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-sinkbinding.adoc @@ -0,0 +1,165 @@ += Using SinkBinding with {SMProductName} +:compat-mode!: +// Metadata: +:description: Using SinkBinding with {SMProductName} + +.Prerequisites + +* You have followed the setup {SMProductShortName} with {ServerlessProductName} procedure + +.Procedure + +. Create a `Service` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: serving.knative.dev/v1 +kind: Service +metadata: + name: event-display + namespace: <1> +spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: "true" <2> + sidecar.istio.io/rewriteAppHTTPProbers: "true" + spec: + containers: + - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the Knative service pods. + +. Apply the `Service` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `SinkBinding`: ++ +[source,yaml] +---- +apiVersion: sources.knative.dev/v1alpha1 +kind: SinkBinding +metadata: + name: bind-heartbeat + namespace: <1> +spec: + subject: + apiVersion: batch/v1 + kind: Job <2> + selector: + matchLabels: + app: heartbeat-cron + + sink: + ref: + apiVersion: serving.knative.dev/v1 + kind: Service + name: event-display +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> In this example, any Job with the label `app: heartbeat-cron` will be bound to the event sink. + +. Apply the `SinkBinding` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `CronJob`: ++ +[source,yaml] +---- +apiVersion: batch/v1 +kind: CronJob +metadata: + name: heartbeat-cron + namespace: <1> +spec: + # Run every minute + schedule: "* * * * *" + jobTemplate: + metadata: + labels: + app: heartbeat-cron + bindings.knative.dev/include: "true" + spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: "true" <2> + sidecar.istio.io/rewriteAppHTTPProbers: "true" + spec: + restartPolicy: Never + containers: + - name: single-heartbeat + image: quay.io/openshift-knative/heartbeats:latest + args: + - --period=1 + env: + - name: ONE_SHOT + value: "true" + - name: POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name + - name: POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the `CronJob` pods. + +. Apply the `CronJob` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Verification + +You can verify that the events were sent to the Knative event sink by looking at the message dumper function logs. + +. Enter the command: ++ +[source,terminal] +---- +$ oc get pods +---- + +. Enter the command: ++ +[source,terminal] +---- +$ oc logs $(oc get pod -o name | grep event-display) -c user-container +---- ++ +.Example output +[source,terminal] +---- +☁️ cloudevents.Event +Validation: valid +Context Attributes, + specversion: 1.0 + type: dev.knative.eventing.samples.heartbeat + source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod + id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 + time: 2019-10-18T15:23:20.809775386Z + contenttype: application/json +Extensions, + beats: true + heart: yes + the: 42 +Data, + { + "id": 1, + "label": "" + } +---- From 68d6a9585ef0ad326e6fc5003170c65d15b62acb Mon Sep 17 00:00:00 2001 From: Pierangelo Di Pilato Date: Mon, 12 Jun 2023 15:05:59 +0200 Subject: [PATCH 2/4] List all namespaces in important Signed-off-by: Pierangelo Di Pilato --- .../pages/service-mesh/eventing-service-mesh-setup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc index fd0801d2..d62d6f68 100644 --- a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc @@ -43,7 +43,7 @@ spec: + [IMPORTANT] ==== -This list of namespaces must include the `knative-serving` namespace. +This list of namespaces must include the `knative-serving` and `knative-eventing` namespaces. ==== . Apply the `ServiceMeshMemberRoll` resource: From 0cbd9887ed7c40089c821a5bb06725aff85862ce Mon Sep 17 00:00:00 2001 From: Pierangelo Di Pilato Date: Tue, 13 Jun 2023 13:39:58 +0200 Subject: [PATCH 3/4] Document authorization policy for MTChannelBasedBroker Signed-off-by: Pierangelo Di Pilato --- modules/ROOT/nav.adoc | 1 + ...mt-channel-based-broker-authorization.adoc | 328 ++++++++++++++++++ .../eventing-service-mesh-setup.adoc | 2 + 3 files changed, 331 insertions(+) create mode 100644 modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 68c6a652..b6d5c0ac 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -4,6 +4,7 @@ *** xref:serverless-eventing:service-mesh/eventing-service-mesh-setup.adoc[Setup Eventing with OpenShift Service Mesh] *** xref:serverless-eventing:service-mesh/eventing-service-mesh-containersource.adoc[Using ContainerSource with OpenShift Service Mesh] *** xref:serverless-eventing:service-mesh/eventing-service-mesh-sinkbinding.adoc[Using SinkBinding with OpenShift Service Mesh] +*** xref:serverless-eventing:service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc[Access control for Knative Broker with class MTChannelBasedBroker using OpenShift Service Mesh] * Serverless Logic ** xref:serverless-logic:about.adoc[About OpenShift Serverless Logic] ** User Guides diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc new file mode 100644 index 00000000..ebc932b9 --- /dev/null +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc @@ -0,0 +1,328 @@ += Access control for Knative Broker with class MTChannelBasedBroker using {SMProductName} +:compat-mode!: +// Metadata: +:description: Access control for Knative Brokers with {SMProductName} + +By default, every workload is allowed to send events to a Knative Broker, with {SMProductName}, we can +apply policies to control who can post events to Knative brokers. + +.Prerequisites + +* You have followed the setup {SMProductShortName} with {ServerlessProductName} procedure. + +.Setup procedure + +. Create a `Broker` with class `MTChannelBasedBroker` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: eventing.knative.dev/v1 +kind: Broker +metadata: + name: channel-based-broker-br + namespace: authz-tests <1> + annotations: + eventing.knative.dev/broker.class: MTChannelBasedBroker +spec: + config: + apiVersion: v1 + kind: ConfigMap + name: config-br-default-channel + namespace: knative-eventing +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. + +. Apply the `Broker` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `ContainerSource` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: sources.knative.dev/v1 +kind: ContainerSource +metadata: + name: heartbeat-source-mt-channel-based-broker + namespace: authz-tests <1> +spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: 'true' <2> + spec: + containers: + - image: quay.io/openshift-knative/heartbeats + name: heartbeats + args: + - --period=1 + env: + - name: POD_NAME + value: "mypod" + - name: POD_NAMESPACE + value: "authz-tests" + sink: + ref: + apiVersion: eventing.knative.dev/v1 + kind: Broker + name: channel-based-broker-br +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the `ContainerSource` pods. + +. Apply the `ContainerSource` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a consumer service, consisting of `Trigger`, `Service`, and `Pod`, in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: eventing.knative.dev/v1 +kind: Trigger +metadata: + name: channel-based-broker-tr + namespace: authz-tests <1> +spec: + broker: channel-based-broker-br + subscriber: + ref: + apiVersion: v1 + kind: Service + name: event-display +--- +apiVersion: v1 +kind: Service +metadata: + name: event-display + namespace: authz-tests <1> +spec: + selector: + app: event-display + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +--- +apiVersion: v1 +kind: Pod +metadata: + name: event-display + namespace: authz-tests <1> + annotations: + sidecar.istio.io/inject: 'true' <2> + labels: + app: event-display +spec: + containers: + - name: event-display + image: quay.io/openshift-knative/knative-eventing-sources-event-display + ports: + - containerPort: 8080 +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the pod. + +. Apply the consumer service resources: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Securing access to the Knative Broker + +By default, every workload is allowed to send events to a Knative Broker, with {SMProductName}, we can +apply a policy to deny posting events by default. + +.Apply a deny by default authorization policy + +. Create a deny by default `AuthorizationPolicy` in the `knative-eventing` namespace: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: deny-all-by-default + namespace: knative-eventing +spec: { } <1> +---- +<1> Disallow any operations to every workload that is part of the service mesh in the `knative-eventing` namespace. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Verify access is denied + ++ +we have denied access to every workload to the knative-eventing namespace, which disallows the +`ContainerSource` `heartbeat-source-mt-channel-based-broker` to send events to the Knative `Broker` +`channel-based-broker-br`, therefore, we should see the following lines in the `heartbeats` pods: + ++ +[source,terminal] +---- +$ oc logs $(oc get pod -n authz-tests -o name | grep heartbeat-source-mt-channel-based-broker) -c heartbeats -n authz-tests +---- ++ +.Example output +[source,terminal] +---- +2023/06/13 10:17:04 sending cloudevent to http://broker-ingress.knative-eventing.svc.cluster.local/authz-tests/channel-based-broker-br +2023/06/13 10:17:04 failed to send cloudevent: 403: +2023/06/13 10:17:05 sending cloudevent to http://broker-ingress.knative-eventing.svc.cluster.local/authz-tests/channel-based-broker-br +2023/06/13 10:17:05 failed to send cloudevent: 403: +---- + +.Authorize source to post events to Knative Broker + +In the previous section, we denied access to Knative Eventing workloads, to grant permissions to +post events to a Knative Broker with class MTChannelBasedBroker. + +. Create a `AuthorizationPolicy` in the `knative-eventing` namespace to allow pods +in the `authz-tests` namespace to send events to Knative Brokers in the same `authz-tests` namespace: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-authz-tests-mt-channel-based-broker + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "broker-ingress" <2> + rules: + - from: <1> + - source: + namespaces: [ "authz-tests" ] + to: <2> + - operation: + methods: [ "POST" ] + paths: [ "/authz-tests/*" ] <3> +---- +<1> Allow workloads in the `authz-tests` namespace +<2> To post events to Knative brokers in the `authz-tests` namespace. +<3> Knative Broker with class MTChannelBasedBroker accepts events on HTTP path following the pattern: `//`. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `AuthorizationPolicy` in the `knative-eventing` namespace to allow `mt-broker-ingress` in +the `knative-eventing` namespace to post events to the `InMemoryChannel` dispatcher: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-mt-channel-based-broker-ingress-to-imc-dispatcher + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "imc-dispatcher" <2> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ] + to: <2> + - operation: + methods: [ "POST" ] +---- +<1> Allow `mt-broker-ingress` in the `knative-eventing` namespace. +<2> To post events to the `InMemoryChannel` dispatcher. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `AuthorizationPolicy` in the `knative-eventing` namespace to allow `imc-dispatcher` in +the `knative-eventing` namespace to post events to the `mt-broker-filter`: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-imc-dispatcher-to-mt-channel-based-broker-filter + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "broker-filter" <2> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/imc-dispatcher" ] + to: <2> + - operation: + methods: [ "POST" ] +---- +<1> Allow `imc-dispatcher` in the `knative-eventing` namespace. +<2> To post events to the `mt-broker-filter`. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Verification + +You can verify that the events were sent to the Knative event sink by looking at the message dumper function logs. + +. Enter the command: ++ +[source,terminal] +---- +$ oc logs $(oc get pod -n authz-tests -o name | grep event-display) -c event-display -n authz-tests +---- ++ +.Example output +[source,terminal] +---- +☁️ cloudevents.Event +Validation: valid +Context Attributes, + specversion: 1.0 + type: dev.knative.eventing.samples.heartbeat + source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod + id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 + time: 2019-10-18T15:23:20.809775386Z + contenttype: application/json +Extensions, + beats: true + heart: yes + the: 42 +Data, + { + "id": 1, + "label": "" + } +---- diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc index d62d6f68..7f91d510 100644 --- a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-setup.adoc @@ -37,9 +37,11 @@ spec: members: <1> - knative-serving - knative-eventing + - authz-tests <2> - ---- <1> A list of namespaces to be integrated with {SMProductShortName}. +<2> Example namespace that will be used to showcase certain functionalities. + [IMPORTANT] ==== From 75961a7a6fbe46957006adaa7d49eaa41a523f07 Mon Sep 17 00:00:00 2001 From: Pierangelo Di Pilato Date: Tue, 20 Jun 2023 11:28:58 +0200 Subject: [PATCH 4/4] Add Kafka Broker and KafkaChannel authorization policies Signed-off-by: Pierangelo Di Pilato --- modules/ROOT/nav.adoc | 2 + ...rvice-mesh-kafka-broker-authorization.adoc | 345 +++++++++++++++++ ...vice-mesh-kafka-channel-authorization.adoc | 348 ++++++++++++++++++ ...mt-channel-based-broker-authorization.adoc | 8 +- 4 files changed, 699 insertions(+), 4 deletions(-) create mode 100644 modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-broker-authorization.adoc create mode 100644 modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-channel-authorization.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index b6d5c0ac..8ae07783 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -5,6 +5,8 @@ *** xref:serverless-eventing:service-mesh/eventing-service-mesh-containersource.adoc[Using ContainerSource with OpenShift Service Mesh] *** xref:serverless-eventing:service-mesh/eventing-service-mesh-sinkbinding.adoc[Using SinkBinding with OpenShift Service Mesh] *** xref:serverless-eventing:service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc[Access control for Knative Broker with class MTChannelBasedBroker using OpenShift Service Mesh] +*** xref:serverless-eventing:service-mesh/eventing-service-mesh-kafka-broker-authorization.adoc[Access control for Knative Broker with class Kafka using OpenShift Service Mesh] +*** xref:serverless-eventing:service-mesh/eventing-service-mesh-kafka-channel-authorization.adoc[Access control for Knative Channel for Apache Kafka using OpenShift Service Mesh] * Serverless Logic ** xref:serverless-logic:about.adoc[About OpenShift Serverless Logic] ** User Guides diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-broker-authorization.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-broker-authorization.adoc new file mode 100644 index 00000000..31f400af --- /dev/null +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-broker-authorization.adoc @@ -0,0 +1,345 @@ += Access control for Knative Broker with class Kafka using {SMProductName} +:compat-mode!: +// Metadata: +:description: Access control for Knative Broker with class Kafka using {SMProductName} + +By default, every workload is allowed to send events to a Knative Broker, with {SMProductName}, we can +apply policies to control who can post events to Knative brokers for Apache Kafka. + +.Prerequisites + +* You have followed the setup {SMProductShortName} with {ServerlessProductName} procedure. + +.Setup procedure + +. Create a `Broker` with class `Kafka` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: eventing.knative.dev/v1 +kind: Broker +metadata: + name: kafka-broker-br + namespace: authz-tests <1> + annotations: + eventing.knative.dev/broker.class: Kafka +spec: + config: + apiVersion: v1 + kind: ConfigMap + name: kafka-broker-config + namespace: knative-eventing +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. + +. Apply the `Broker` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `ContainerSource` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: sources.knative.dev/v1 +kind: ContainerSource +metadata: + name: heartbeat-source-kafka-broker + namespace: authz-tests <1> +spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: 'true' <2> + spec: + containers: + - image: quay.io/openshift-knative/heartbeats + name: heartbeats + args: + - --period=1 + env: + - name: POD_NAME + value: "mypod" + - name: POD_NAMESPACE + value: "authz-tests" + sink: + ref: + apiVersion: eventing.knative.dev/v1 + kind: Broker + name: kafka-broker-br +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the `ContainerSource` pods. + +. Apply the `ContainerSource` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a consumer service, consisting of `Trigger`, `Service`, and `Pod`, in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: eventing.knative.dev/v1 +kind: Trigger +metadata: + name: kafka-broker-tr + namespace: authz-tests <1> +spec: + broker: kafka-broker-br + subscriber: + ref: + apiVersion: v1 + kind: Service + name: event-display +--- +apiVersion: v1 +kind: Service +metadata: + name: event-display + namespace: authz-tests <1> +spec: + selector: + app: event-display + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +--- +apiVersion: v1 +kind: Pod +metadata: + name: event-display + namespace: authz-tests <1> + annotations: + sidecar.istio.io/inject: 'true' <2> + labels: + app: event-display +spec: + containers: + - name: event-display + image: quay.io/openshift-knative/knative-eventing-sources-event-display + ports: + - containerPort: 8080 +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the pod. + +. Apply the consumer service resources: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Securing access to the Knative broker for Apache Kafka + +By default, every workload is allowed to send events to a Knative broker, with {SMProductName}, we can +apply a policy to deny posting events by default. + +.Apply a deny by default authorization policy + +. Create a deny by default `AuthorizationPolicy` in the `knative-eventing` namespace: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: deny-all-by-default + namespace: knative-eventing +spec: { } <1> +---- +<1> Disallow any operations to every workload that is part of the service mesh in the `knative-eventing` namespace. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Verify access is denied + ++ +we have denied access to every workload to the knative-eventing namespace, which disallows the +`ContainerSource` `heartbeat-source-kafka-broker` to send events to the Knative `Broker` +`kafka-broker-br`, therefore, we should see the following lines in the `heartbeats` pods: + ++ +[source,terminal] +---- +$ oc logs $(oc get pod -n authz-tests -o name | grep heartbeat-source-kafka-broker) -c heartbeats -n authz-tests +---- ++ +.Example output +[source,terminal] +---- +2023/06/13 10:17:04 sending cloudevent to http://kafka-broker-ingress.knative-eventing.svc.cluster.local/authz-tests/kafka-broker-br +2023/06/13 10:17:04 failed to send cloudevent: 403: +2023/06/13 10:17:05 sending cloudevent to http://kafka-broker-ingress.knative-eventing.svc.cluster.local/authz-tests/kafka-broker-br +2023/06/13 10:17:05 failed to send cloudevent: 403: +---- + +.Authorize Knative Kafka controller to probe Knative Kafka resources + +The `kafka-controller` component probes Knative resources for readiness, so that it +can report and mark them as `Ready` when they are actually ready to serve requests. + +Probes are HTTP(S) GET requests sent from the `kafka-controller` to the data plane pods, including: +`kafka-broker-receiver`, `kafka-channel-receiver`, and `kafka-sink-receiver`. + +To authorize the `kafka-controller` to send probe requests, we can: + +. Create `AuthorizationPolicy` in the `knative-eventing` namespace to allow Knative Kafka controller +in the `knative-eventing` namespace to probe for readiness Knative Kafka resources: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-probe-kafka-broker-receiver + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-broker-receiver" <2> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ] + to: <2> + - operation: + methods: [ "GET" ] +--- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-probe-kafka-sink-receiver + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-sink-receiver" <3> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ] + to: <3> + - operation: + methods: [ "GET" ] +--- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-probe-kafka-channel-receiver + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-channel-receiver" <4> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ] + to: <4> + - operation: + methods: [ "GET" ] +---- +<1> Allow the Knative Kafka controller +<2> To probe the Knative Kafka Broker receiver +<3> To probe the Knative Kafka Sink receiver +<4> To probe the Knative Kafka Channel receiver + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Authorize source to post events to Knative broker for Apache Kafka + +In the previous section, we denied access to Knative Eventing workloads, we can now grant permissions to +post events to a Knative Broker with class Kafka: + +. Create a `AuthorizationPolicy` in the `knative-eventing` namespace to allow pods +in the `authz-tests` namespace to send events to Knative Brokers in the same `authz-tests` namespace: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-authz-tests-kafka-broker + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-broker-receiver" <2> + rules: + - from: <1> + - source: + namespaces: [ "authz-tests" ] + to: <2> + - operation: + methods: [ "POST" ] + paths: [ "/authz-tests/*" ] <3> +---- +<1> Allow workloads in the `authz-tests` namespace +<2> To post events to Knative brokers in the `authz-tests` namespace. +<3> Knative Broker with class `Kafka` accepts events on HTTP path following the pattern: `//`. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Verification + +You can verify that the events were sent to the Knative event sink by looking at the message dumper function logs. + +. Enter the command: ++ +[source,terminal] +---- +$ oc logs $(oc get pod -n authz-tests -o name | grep event-display) -c event-display -n authz-tests +---- ++ +.Example output +[source,terminal] +---- +# TODO: fix output +☁️ cloudevents.Event +Validation: valid +Context Attributes, + specversion: 1.0 + type: dev.knative.eventing.samples.heartbeat + source: https://knative.dev/eventing-contrib/cmd/heartbeats/#authz-tests/mypod + id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 + time: 2019-10-18T15:23:20.809775386Z + contenttype: application/json +Extensions, + beats: true + heart: yes + the: 42 +Data, + { + "id": 1, + "label": "" + } +---- diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-channel-authorization.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-channel-authorization.adoc new file mode 100644 index 00000000..baa143ba --- /dev/null +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-kafka-channel-authorization.adoc @@ -0,0 +1,348 @@ += Access control for Knative channel for Apache Kafka using {SMProductName} +:compat-mode!: +// Metadata: +:description: Access control for Knative channel for Apache Kafka using {SMProductName} + +By default, every workload is allowed to send events to a Knative channel, with {SMProductName}, we can +apply policies to control who can post events to Knative channels for Apache Kafka. + +.Prerequisites + +* You have followed the setup {SMProductShortName} with {ServerlessProductName} procedure. + +.Setup procedure + +. Create a `KafkaChannel` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: messaging.knative.dev/v1beta1 +kind: KafkaChannel +metadata: + name: kafka-channel + namespace: authz-tests <1> +spec: + numPartitions: 10 + replicationFactor: 3 + delivery: + retry: 12 + backoffPolicy: exponential + backoffDelay: PT1S +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. + +. Apply the `KafkaChannel` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a `ContainerSource` in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: sources.knative.dev/v1 +kind: ContainerSource +metadata: + name: heartbeat-source-kafka-channel + namespace: authz-tests <1> +spec: + template: + metadata: + annotations: + sidecar.istio.io/inject: 'true' <2> + spec: + containers: + - image: quay.io/openshift-knative/heartbeats + name: heartbeats + args: + - --period=1 + env: + - name: POD_NAME + value: "mypod-channel" + - name: POD_NAMESPACE + value: "authz-tests" + sink: + ref: + apiVersion: messaging.knative.dev/v1beta1 + kind: KafkaChannel + name: kafka-channel +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the `ContainerSource` pods. + +. Apply the `ContainerSource` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Create a consumer service, consisting of `Subscription`, `Service`, and `Pod`, in a namespace that is member of the `ServiceMeshMemberRoll`: ++ +[source,yaml] +---- +apiVersion: messaging.knative.dev/v1 +kind: Subscription +metadata: + name: subscription + namespace: authz-tests <1> +spec: + channel: + apiVersion: messaging.knative.dev/v1beta1 + kind: KafkaChannel + name: kafka-channel + subscriber: + ref: + apiVersion: v1 + kind: Service + name: event-display +--- +apiVersion: v1 +kind: Service +metadata: + name: event-display + namespace: authz-tests <1> +spec: + selector: + app: event-display + ports: + - protocol: TCP + port: 80 + targetPort: 8080 +--- +apiVersion: v1 +kind: Pod +metadata: + name: event-display + namespace: authz-tests <1> + annotations: + sidecar.istio.io/inject: 'true' <2> + labels: + app: event-display +spec: + containers: + - name: event-display + image: quay.io/openshift-knative/knative-eventing-sources-event-display + ports: + - containerPort: 8080 +---- +<1> A namespace that is member of the `ServiceMeshMemberRoll`. +<2> Injects {SMProductShortName} sidecars into the pod. + +. Apply the consumer service resources: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Securing access to the Knative channel for Apache Kafka + +By default, every workload is allowed to send events to a Knative channel, with {SMProductName}, we can +apply a policy to deny posting events by default. + +.Apply a deny by default authorization policy + +. Create a deny by default `AuthorizationPolicy` in the `knative-eventing` namespace: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: deny-all-by-default + namespace: knative-eventing +spec: { } <1> +---- +<1> Disallow any operations to every workload that is part of the service mesh in the `knative-eventing` namespace. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +. Verify access is denied + ++ +we have denied access to every workload to the knative-eventing namespace, which disallows the +`ContainerSource` `heartbeat-source-kafka-channel` to send events to the Knative `KafkaChannel` +`kafka-channel`, therefore, we should see the following lines in the `heartbeats` pods: + ++ +[source,terminal] +---- +$ oc logs $(oc get pod -n authz-tests -o name | grep heartbeat-source-kafka-channel) -c heartbeats -n authz-tests +---- ++ +.Example output +[source,terminal] +---- +# TODO: fix output +2023/06/13 10:17:04 sending cloudevent to http://kafka-channel-ingress.knative-eventing.svc.cluster.local/authz-tests/kafka-broker-br +2023/06/13 10:17:04 failed to send cloudevent: 403: +2023/06/13 10:17:05 sending cloudevent to http://kafka-broker-ingress.knative-eventing.svc.cluster.local/authz-tests/kafka-broker-br +2023/06/13 10:17:05 failed to send cloudevent: 403: +---- + +.Authorize Knative Kafka controller to probe Knative Kafka resources + +The `kafka-controller` component probes Knative resources for readiness, so that it +can report and mark them as `Ready` when they are actually ready to serve requests. + +Probes are HTTP(S) GET requests sent from the `kafka-controller` to the data plane pods, including: +`kafka-broker-receiver`, `kafka-channel-receiver`, and `kafka-sink-receiver`. + +To authorize the `kafka-controller` to send probe requests, we can: + +. Create `AuthorizationPolicy` in the `knative-eventing` namespace to allow Knative Kafka controller +in the `knative-eventing` namespace to probe for readiness Knative Kafka resources: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-probe-kafka-broker-receiver + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-broker-receiver" <2> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ] + to: <2> + - operation: + methods: [ "GET" ] +--- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-probe-kafka-sink-receiver + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-sink-receiver" <3> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ] + to: <3> + - operation: + methods: [ "GET" ] +--- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-probe-kafka-channel-receiver + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-channel-receiver" <4> + rules: + - from: <1> + - source: + namespaces: [ "knative-eventing" ] + principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ] + to: <4> + - operation: + methods: [ "GET" ] +---- +<1> Allow the Knative Kafka controller +<2> To probe the Knative Kafka Broker receiver +<3> To probe the Knative Kafka Sink receiver +<4> To probe the Knative Kafka Channel receiver + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Authorize source to post events to Knative channel for Apache Kafka + +In the previous section, we denied access to Knative Eventing workloads, we can now grant permissions to +post events to a Knative Broker with class Kafka: + +. Create a `AuthorizationPolicy` in the `knative-eventing` namespace to allow pods +in the `authz-tests` namespace to send events to Knative Brokers in the same `authz-tests` namespace: ++ +[source,yaml] +---- +apiVersion: security.istio.io/v1beta1 +kind: AuthorizationPolicy +metadata: + name: allow-authz-tests-kafka-channel + namespace: knative-eventing +spec: + action: ALLOW + selector: + matchLabels: + app.kubernetes.io/component: "kafka-channel-receiver" <2> + rules: + - from: <1> + - source: + namespaces: [ "authz-tests" ] + to: <2> + - operation: + hosts: [ "*.authz-tests.svc.cluster.local" ] <3> + methods: [ "POST" ] +---- +<1> Allow workloads in the `authz-tests` namespace +<2> To post events to Knative channels for Apache Kafka in the `authz-tests` namespace. +<3> Knative channel for Apache Kafka accepts events on HTTP host following the pattern: `..svc.`. + +. Apply the `AuthorizationPolicy` resource: ++ +[source,terminal] +---- +$ oc apply -f +---- + +.Verification + +You can verify that the events were sent to the Knative event sink by looking at the message dumper function logs. + +. Enter the command: ++ +[source,terminal] +---- +$ oc logs $(oc get pod -n authz-tests -o name | grep event-display) -c event-display -n authz-tests +---- ++ +.Example output +[source,terminal] +---- +# TODO: fix output +☁️ cloudevents.Event +Validation: valid +Context Attributes, + specversion: 1.0 + type: dev.knative.eventing.samples.heartbeat + source: https://knative.dev/eventing-contrib/cmd/heartbeats/#authz-tests/mypod + id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 + time: 2019-10-18T15:23:20.809775386Z + contenttype: application/json +Extensions, + beats: true + heart: yes + the: 42 +Data, + { + "id": 1, + "label": "" + } +---- diff --git a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc index ebc932b9..d1e8bf73 100644 --- a/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc +++ b/modules/serverless-eventing/pages/service-mesh/eventing-service-mesh-mt-channel-based-broker-authorization.adoc @@ -1,7 +1,7 @@ = Access control for Knative Broker with class MTChannelBasedBroker using {SMProductName} :compat-mode!: // Metadata: -:description: Access control for Knative Brokers with {SMProductName} +:description: Access control for Knative Broker with class MTChannelBasedBroker using {SMProductName} By default, every workload is allowed to send events to a Knative Broker, with {SMProductName}, we can apply policies to control who can post events to Knative brokers. @@ -187,8 +187,8 @@ $ oc logs $(oc get pod -n authz-tests -o name | grep heartbeat-source-mt-channel .Authorize source to post events to Knative Broker -In the previous section, we denied access to Knative Eventing workloads, to grant permissions to -post events to a Knative Broker with class MTChannelBasedBroker. +In the previous section, we denied access to Knative Eventing workloads, we can now grant permissions to +post events to a Knative Broker with class MTChannelBasedBroker: . Create a `AuthorizationPolicy` in the `knative-eventing` namespace to allow pods in the `authz-tests` namespace to send events to Knative Brokers in the same `authz-tests` namespace: @@ -216,7 +216,7 @@ spec: ---- <1> Allow workloads in the `authz-tests` namespace <2> To post events to Knative brokers in the `authz-tests` namespace. -<3> Knative Broker with class MTChannelBasedBroker accepts events on HTTP path following the pattern: `//`. +<3> Knative Broker with class `MTChannelBasedBroker` accepts events on HTTP path following the pattern: `//`. . Apply the `AuthorizationPolicy` resource: +