SRVKS-562: Restrictive network policy docs for Knative services

modules/serverless-services-network-policies.adoc

@@ -0,0 +1,84 @@
+[id="serverless-services-network-policies_{context}"]
+= Enabling communication with Knative applications on a cluster with restrictive network policies
+
+If you are using a cluster that multiple users have access to, your cluster might use network policies to control which pods, services, and namespaces can communicate with each other over the network.
+
+If your cluster uses restrictive network policies, it is possible that Knative system pods are not able to access your Knative application. For example, if your namespace has the following network policy, which denies all requests, Knative system pods cannot access your Knative application:
+
+.Example NetworkPolicy object that denies all requests to the namespace
+[source,yaml]
+----
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+  name: deny-by-default
+  namespace: example-namespace
+spec:
+  podSelector:
+  ingress: []
+----
+
+To allow access to your applications from Knative system pods, you must add a label to each of the Knative system namespaces, and then create a `NetworkPolicy` object in your application namespace that allows access to the namespace for other namespaces that have this label.
+
+[IMPORTANT]
+====
+A network policy that denies requests to non-Knative services on your cluster still prevents access to these services. However, by allowing access from Knative system namespaces to your Knative application, you are allowing access to your Knative application from all namespaces in the cluster.
+
+If you do not want to allow access to your Knative application from all namespaces on the cluster, you might want to use _JSON Web Token authentication for Knative services_ instead (see the _Knative Serving_ documentation). JSON Web Token authentication for Knative services requires Service Mesh.
+====
+// xrefs for modules would be nice here to link to the JWT docs
+
+.Procedure
+
+. Add the `knative.openshift.io/system-namespace=true` label to each Knative system namespace that requires access to your application:
+
+.. Label the `knative-serving` namespace:
++
+[source, terminal]
+----
+$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
+----
+
+.. Label the `knative-serving-ingress` namespace:
++
+[source, terminal]
+----
+$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
+----
+
+.. Label the `knative-eventing` namespace:
++
+[source, terminal]
+----
+$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
+----
+
+.. Label the `knative-kafka` namespace:
++
+[source, terminal]
+----
+$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
+----
+
+. Create a `NetworkPolicy` object in your application namespace to allow access from namespaces with the `knative.openshift.io/system-namespace` label:
++
+.Example `NetworkPolicy` object
+[source,yaml]
+----
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: <network_policy_name> <1>
+  namespace: <namespace> <2>
+spec:
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          knative.openshift.io/system-namespace: "true"
+  podSelector: {}
+  policyTypes:
+  - Ingress
+----
+<1> Provide a name for your network policy.
+<2> The namespace where your application (Knative service) exists.

serverless/knative_serving/serverless-applications.adoc

@@ -35,6 +35,9 @@ include::modules/kn-service-describe.adoc[leveloffset=+1]
 include::modules/verifying-serverless-app-deployment.adoc[leveloffset=+1]
 include::modules/interacting-serverless-apps-http2-gRPC.adoc[leveloffset=+1]
 
+// Using Knative services w/ restrictive NetworkPolicies
+include::modules/serverless-services-network-policies.adoc[leveloffset=+1]
+
 [id="serverless-applications-kn-offline-mode"]
 == Using kn CLI in offline mode