Skip to content

Fix format #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 23, 2023
Merged

Fix format #2

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 12 additions & 10 deletions ...serverless-common/pages/service-mesh/common-service-mesh-network-isolation.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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*

Expand All @@ -20,6 +20,7 @@ image::service-mesh/multi-tenancy-service-mesh-Serving.drawio.svg[]
image::service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg[]

.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}.
Expand All @@ -28,6 +29,7 @@ image::service-mesh/multi-tenancy-service-mesh-Eventing.drawio.svg[]


.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]
Expand All @@ -45,8 +47,7 @@ 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:
+
Expand Down Expand Up @@ -231,10 +232,11 @@ 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:
Expand All @@ -244,8 +246,7 @@ Make sure to apply all those rules to your cluster with:
$ oc apply -f <filename>
----

. 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
Expand All @@ -268,11 +269,12 @@ $ oc apply -f <filename>
+
[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:

Expand Down