From e043ee135671fe0f2ee1ffd4f5b44cd2c4ef0b1e Mon Sep 17 00:00:00 2001 From: Pierangelo Di Pilato Date: Wed, 23 Aug 2023 09:36:06 +0200 Subject: [PATCH 1/2] Format document Signed-off-by: Pierangelo Di Pilato --- ...common-service-mesh-network-isolation.adoc | 23 ++++++++----------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc b/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc index 5ca86299..532ff283 100644 --- a/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc +++ b/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc @@ -7,9 +7,9 @@ {smproductshortname} can be used to isolate network-traffic between "tenants" using {smproductshortname} `AuthorizationPolicy` resources. {serverlessproductname} can also leverage this, using several {smproductshortname} resources. - .High-level architecture -The high-level architecture consists of `AuthorizationPolicies` in the `knative-serving`, `knative-eventing` and the tenants namespaces, while all components are part of the {smproductshortname}. The respective `istio-proxy` sidecars take care of enforcing those rules to isolate traffic between tenants. +The high-level architecture consists of `AuthorizationPolicies` in the `knative-serving`, `knative-eventing` and the tenants namespaces, while all components are part of the {smproductshortname}. +The respective `istio-proxy` sidecars take care of enforcing those rules to isolate traffic between tenants. *Knative Serving* @@ -19,9 +19,7 @@ image::service-mesh/multi-tenancy-service-mesh.drawio.svg[] TODO pierdipi, please add your diagram here! - .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}. @@ -30,7 +28,6 @@ TODO pierdipi, please add your diagram here! .Securing the {smproductshortname} - . As in the set-up documentation, make sure that all your tenants are part of the same `ServiceMeshMemberRoll` object as members: + [source,yaml] @@ -48,7 +45,8 @@ spec: - tenant-2 ---- + -All the namespaces that are part of the Mesh must enforce mTLS in strict mode. This forces Istio to only accept connections with a client-certificate present and allows the `istio-proxy` to validate the origin using `AuthorizationPolicy`. +All the namespaces that are part of the Mesh must enforce mTLS in strict mode. +This forces Istio to only accept connections with a client-certificate present and allows the `istio-proxy` to validate the origin using `AuthorizationPolicy`. + . For {serverlessproductname} internal components to work, the several `AuthorizationPolicies` are necessary in the `knative-serving` and the `knative-eventing` namespace: + @@ -233,11 +231,10 @@ spec: namespaces: [ "knative-serving" ] --- ---- + These policies: - Deny all traffic that is not explicitly allowed in `knative-serving` and `knative-eventing` -- Allow traffic from `istio-system` and `knative-serving` to activator -- Allow traffic from `knative-serving` to autoscaler -- Allow health probes for kafka components in `knative-eventing` +- Allow traffic from `istio-system` and `knative-serving` to activator - Allow traffic from `knative-serving` to autoscaler - Allow health probes for kafka components in `knative-eventing` - Allow internal traffic for channel based brokers in `knative-eventing` + Make sure to apply all those rules to your cluster with @@ -247,7 +244,8 @@ Make sure to apply all those rules to your cluster with $ oc apply -f ---- -. With this set up in place, cluster administrators can use their own `AuthorizationPolicies` to define which namespaces (tenants) can communicate with each other. Each namespace needs: +. With this set up in place, cluster administrators can use their own `AuthorizationPolicies` to define which namespaces (tenants) can communicate with each other. +Each namespace needs: - One AuthorizationPolicy limiting directly incoming traffic in the tenants namespace - One AuthorizationPolicy limiting incoming traffic via activator in the `knative-serving` namespace - One AuthorizationPolicy allowing Kubernetes to call PreStopHooks on Knative Services @@ -270,12 +268,11 @@ $ oc apply -f + [NOTE] ==== -The helm chart has several options that can be passed to configure the generated resources. Please refer to the link:https://github.com/openshift-knative/knative-istio-authz-chart/blob/main/values.yaml[values.yaml] for a full reference. +The helm chart has several options that can be passed to configure the generated resources. +Please refer to the link:https://github.com/openshift-knative/knative-istio-authz-chart/blob/main/values.yaml[values.yaml] for a full reference. ==== - .Verifying the configuration - This verification is assuming that we have two tenants with one namespace each, all part of the `ServiceMeshMemberRoll`, configured with resources listed above. We can then use curl to verify the connectivity: From b5101c87da440758705684c78edc648cc041fa4a Mon Sep 17 00:00:00 2001 From: Pierangelo Di Pilato Date: Wed, 23 Aug 2023 09:44:34 +0200 Subject: [PATCH 2/2] Add Eventing diagram for Istio authorization policies Signed-off-by: Pierangelo Di Pilato --- .../multi-tenancy-service-mesh-Eventing.drawio.svg | 4 ++++ ...io.svg => multi-tenancy-service-mesh-Serving.drawio.svg} | 0 .../service-mesh/common-service-mesh-network-isolation.adoc | 6 +++--- 3 files changed, 7 insertions(+), 3 deletions(-) create mode 100644 modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg rename modules/serverless-common/assets/images/service-mesh/{multi-tenancy-service-mesh.drawio.svg => multi-tenancy-service-mesh-Serving.drawio.svg} (100%) diff --git a/modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg b/modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg new file mode 100644 index 00000000..430ed33e --- /dev/null +++ b/modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg @@ -0,0 +1,4 @@ + + + +







tenant-1
*.tenant-1.svc.cluster.local
tenant-1...







tenant-2
 *.tenant-2.svc.cluster.local
tenant-2...






    knative-eventing
knative-eventing...
Receiver
Receiver
Sender
Sender
1)
1)
AuthorizationPolicy
from:
    namespaces: ["tenant-1"]
to:
  hosts: ["*.tenant-1.svc.cluster.local"]
  paths: ["/tenant-1/*"]
AuthorizationPolicy...
AuthorizationPolicy
from:
    namespaces: ["tenant-2"]
to:
  hosts: ["*.tenant-2.svc.cluster.local"]
  paths: ["/tenant-2/*"]
AuthorizationPolicy...
Receiver is the last place we know the "real" source.

Sender sends "Kn-Namespace" header with the resource's namespace as value
Receiver is the last place w...
Legend
Legend
tenant-1: all shown paths are allowed
tenant-1: all shown paths are allow...
tenant-2: 
1) tenant-2 can call "receiver" directly and send events to resources in tenant-1 namespace.
2) tenant-2 can not call tenant-1 directly. Rejected in tenant-1 istio-proxy.
3) sources, triggers, and subscribers in tenant-2 namespaces can not call tenant-1 workloads. Rejected in tenant-1 istio-proxy.
tenant-2:...
3)
3)
AuthorizationPolicy
from:
    namespaces: ["knative-eventing"]
when:
    key: request.headers[Kn-Namespace]
    values: ["tenant-1"]
AuthorizationPolicy...
AuthorizationPolicy
from:
    namespaces: ["knative-eventing"]
when:
    key: request.headers[Kn-Namespace]
    values: ["tenant-2"]
AuthorizationPolicy...
ksvc
ksvc
svc
svc
ksvc
ksvc
svc
svcText is not SVG - cannot display \ No newline at end of file diff --git a/modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh.drawio.svg b/modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh-Serving.drawio.svg similarity index 100% rename from modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh.drawio.svg rename to modules/serverless-common/assets/images/service-mesh/multi-tenancy-service-mesh-Serving.drawio.svg diff --git a/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc b/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc index 532ff283..2a8f40e3 100644 --- a/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc +++ b/modules/serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc @@ -13,11 +13,11 @@ The respective `istio-proxy` sidecars take care of enforcing those rules to isol *Knative Serving* -image::service-mesh/multi-tenancy-service-mesh.drawio.svg[] +image::service-mesh/multi-tenancy-service-mesh-Serving.drawio.svg[] *Knative Eventing* -TODO pierdipi, please add your diagram here! +image::service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg[] .Prerequisites * You have access to an {product-title} account with cluster administrator access. @@ -237,7 +237,7 @@ These policies: - Allow traffic from `istio-system` and `knative-serving` to activator - Allow traffic from `knative-serving` to autoscaler - Allow health probes for kafka components in `knative-eventing` - Allow internal traffic for channel based brokers in `knative-eventing` + -Make sure to apply all those rules to your cluster with +Make sure to apply all those rules to your cluster with: + [source,terminal] ----