From a81396839d29687f54f3fc439c7f5441af2a69c5 Mon Sep 17 00:00:00 2001 From: Steven Smith Date: Mon, 14 Apr 2025 15:39:02 -0400 Subject: [PATCH 1/2] Adds egress netpol docs --- _topic_maps/_topic_map.yml | 2 + modules/nw-networkpolicy-allow-internet.adoc | 107 +++++++++++ ...cy-configuring-ingress-new-deployment.adoc | 171 ++++++++++++++++++ ...licy-configuring-internet-egress-pods.adoc | 75 ++++++++ ...kpolicy-cross-namespace-communication.adoc | 127 +++++++++++++ .../nw-networkpolicy-deny-all-allowed.adoc | 1 + ...policy-deny-all-egress-network-policy.adoc | 101 +++++++++++ ...y-enable-pod-pod-communication-egress.adoc | 108 +++++++++++ ...rkpolicy-multitenant-isolation-egress.adoc | 20 ++ ...w-networkpolicy-pod-pod-communication.adoc | 15 ++ ...rkpolicy-same-namespace-communication.adoc | 73 ++++++++ modules/nw-policy-cluster-preparation.adoc | 137 ++++++++++++++ modules/nw-policy-default-deny-ingress.adoc | 122 +++++++++++++ ...-policy-multitenant-isolation-ingress.adoc | 9 + ...workpolicy-full-multitenant-isolation.adoc | 31 ++++ 15 files changed, 1099 insertions(+) create mode 100644 modules/nw-networkpolicy-allow-internet.adoc create mode 100644 modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc create mode 100644 modules/nw-networkpolicy-configuring-internet-egress-pods.adoc create mode 100644 modules/nw-networkpolicy-cross-namespace-communication.adoc create mode 100644 modules/nw-networkpolicy-deny-all-egress-network-policy.adoc create mode 100644 modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc create mode 100644 modules/nw-networkpolicy-multitenant-isolation-egress.adoc create mode 100644 modules/nw-networkpolicy-pod-pod-communication.adoc create mode 100644 modules/nw-networkpolicy-same-namespace-communication.adoc create mode 100644 modules/nw-policy-cluster-preparation.adoc create mode 100644 modules/nw-policy-default-deny-ingress.adoc create mode 100644 modules/nw-policy-multitenant-isolation-ingress.adoc create mode 100644 networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index de5f181d6cc0..fd82ca92b638 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -1479,6 +1479,8 @@ Topics: File: default-network-policy - Name: Configuring multitenant isolation with network policy File: multitenant-network-policy + - Name: Configuring full multitenant isolation with ingress and egress network policies + File: nw-networkpolicy-full-multitenant-isolation - Name: Audit logging for network security File: logging-network-security - Name: Egress Firewall diff --git a/modules/nw-networkpolicy-allow-internet.adoc b/modules/nw-networkpolicy-allow-internet.adoc new file mode 100644 index 000000000000..738e923c6866 --- /dev/null +++ b/modules/nw-networkpolicy-allow-internet.adoc @@ -0,0 +1,107 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-networkpolicy-allow-ingress_{context}"] += Creating an allow ingress access network policy + +With the `deny-by-default` network policy in place, no pods can talk to each other or receive traffic from external sources. One option to enable communication is to allow some pods to receive traffic. To do so, you can create the following `ingress-access` network policy. With this network policy, pods with the `networking/allow-ingress-access=true` label can receive network traffic. + +.Prerequisites + +* You have created the `deny-by-default` network policy and applied it to the necessary namespaces. + +.Procedure + +. Create the following `ingress-access` network policy to allow pods with the `networking/allow-ingress-access` label to receive traffic from outside sources. Save the YAML in the `ingress-access.yaml` file: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: ingress-access +spec: + podSelector: + matchLabels: + networking/allow-ingress-access: "true" <1> + policyTypes: + - Ingress + ingress: + - {} +---- +<1> Apply this label to pods to enable the pod to receive traffic from outside sources. + +. Apply the network policy to the `project-a` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f ingress-access.yaml -n project-a +---- + +. Apply the network policy to the `project-b` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f ingress-access.yaml -n project-b +---- + +. Apply the `networking/allow-ingress-access=true` label to pods that must receive outside traffic by entering the following command: ++ +[source,terminal] +---- +$ oc label pod busybox-pod-a networking/allow-ingress-access=true -n project-a +---- ++ +Repeat this step for all pods that must receive outside traffic. + +.Verification + +. Obtain the IP addresses of pods in `project-a` by running the following command: ++ +[source,terminal] +---- +$ oc get pod -n project-a -o wide +---- ++ +.Example output ++ +[source,terminal] +---- +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +busybox-pod-a 1/1 Running 0 13m 10.132.0.38 ip-10-0-132-187.ec2.internal +test-pod-a 1/1 Running 0 13m 10.132.0.40 ip-10-0-132-187.ec2.internal +---- + +. Ensure that pods with the `networking/allow-ingress-access=true` label can receive traffic by entering the following command. If you followed these instructions, the `busybox-pod-a` pod in `project-a` can receive traffic from another pod. For example: ++ +[source,terminal] +---- +$ oc exec -it test-pod-b -n project-b -- ping 10.132.0.44 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.44 (10.132.0.44): 56 data bytes +64 bytes from 10.132.0.44: seq=0 ttl=42 time=1.137 ms +64 bytes from 10.132.0.44: seq=1 ttl=42 time=0.672 ms +---- + +. Ensure that pods without the `networking/allow-ingress-access=true` label cannot receive traffic by entering the following command. If you followed these instructions, the `test-pod-a` pod in `project-a` cannot receive traffic. For example: ++ +[source,terminal] +---- +$ oc exec -it busybox-pod-a -n project-a -- ping 10.132.0.40 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.40 (10.132.0.40): 56 data bytes +--- 10.132.0.40 ping statistics --- +3 packets transmitted, 0 packets received, 100% packet loss +---- \ No newline at end of file diff --git a/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc b/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc new file mode 100644 index 000000000000..6bf19a74cbf1 --- /dev/null +++ b/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc @@ -0,0 +1,171 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: REFERENCE +[id="nw-networkpolicy-ingress-new-deployments_{context}"] += Creating a network policy for new projects + +After you have created a network policy that defines specific connections, new pods within a project are unable to communicate with existing pods in the same project, until the proper network policy has been applied to that pod. To address this behavior, you can create the following `allow-ingress-from-new` and `allow-ingress-to-new` network policies in a project, which allows new pods with the `networking/allow-all-connections=true` label to communicate with existing pods until more granular policies are created. + +.Prerequisites + +* You have created the `deny-by-default` network policy and applied it to a project. + +.Procedure + +. Create a new project, for example, `project-c`, by running the following command: ++ +[source,terminal] +---- +$ oc new-project project-c +---- + +. In the `project-c` namespace, create a new pod by running the following command: ++ +[source,terminal] +---- +$ cat < networking/allow-all-connections=true -n project-a +---- + +. In the `project-c` namespace: + +.. Create the following `allow-ingress-from-new` network policy, which allows pods in this project the ability to receive ingress from a new project: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-ingress-from-new +spec: + podSelector: {} + policyTypes: + - Ingress + ingress: + - from: + - podSelector: + matchLabels: + networking/allow-all-connections: "true" +---- + +.. Apply the network policy by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f allow-ingress-from-new.yaml -n project-c +---- + +.. Create the following `allow-ingress-to-new` network policy, which allows pods in this project the ability to send ingress to a new project: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-ingress-to-new +spec: + podSelector: + matchLabels: + networking/allow-all-connections: "true" + policyTypes: + - Ingress + ingress: + - from: + - podSelector: {} +---- + +.. Apply the network policy by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f allow-ingress-tp-new.yaml -n project-c +---- + +.. Apply the `networking/allow-all-connections=true` to pods in `project-c` that you want to be able to communicate with pods in `project-a` by running the following command: ++ +[source,terminal] +---- +$ oc label pod busybox-pod networking/allow-all-connections=true -n project-c +---- diff --git a/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc b/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc new file mode 100644 index 000000000000..cac6f87523c8 --- /dev/null +++ b/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc @@ -0,0 +1,75 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-networkpolicy-configuring-internet-egress-pods_{context}"] += Configuring internet egress for pods + +With the deny all egress network policy created in a namespace, pods within that namespace are made incapable of reaching _out_ to the internet. In most cases, at least some pods within a namespace need to reach external traffic. + +The following procedure shows you how to designate labels to pods that require internet egress. + +.Prerequisites + +* You have created a network policy to deny all egress traffic. + +.Procedure + +. Create the following `internet-egress.yaml` file that both defines a network policy that allows traffic from pods with the matching label to access internet egress. For example: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: internet-egress +spec: + podSelector: + matchLabels: + networking/allow-internet-egress: "true" <1> + egress: + - {} + policyTypes: + - Egress +---- + +. Apply the network policy to the `project-a` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f internet-egress.yaml -n project-a +---- + +. Apply the network policy to the `project-b` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f internet-egress.yaml -n project-b +---- + +. Apply the `networking/allow-internet-egress=true` label to pods that require egress by entering the following command: ++ +[source,terminal] +---- +$ oc label pod busybox-pod-a networking/allow-internet-egress=true -n project-a +---- + +.Verification + +* Check whether a labeled pod in a namespace where you applied the `internet-egress.yaml` network policy can resolve a DNS name by entering the following command: ++ +[source,terminal] +---- +$ oc exec -it -n project-a -- nslookup google.com +---- ++ +.Example output ++ +[source,terminal] +---- +... +Name: google.com +Address: 142.250.125.102 +... +---- \ No newline at end of file diff --git a/modules/nw-networkpolicy-cross-namespace-communication.adoc b/modules/nw-networkpolicy-cross-namespace-communication.adoc new file mode 100644 index 000000000000..d9178f105aee --- /dev/null +++ b/modules/nw-networkpolicy-cross-namespace-communication.adoc @@ -0,0 +1,127 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: REFERENCE +[id="nw-networkpolicy-cross-namespace-communication_{context}"] += Creating a network policy for cross-namespace communication + +To allow pod-to-pod communication across namespaces, you must create a label for the primary namespace and add a `namespaceSelector` query and a `podSelector` query. + +.Prerequisites + +* You have created the `deny-by-default` network policy and applied it to all necessary namespaces. + +.Procedure + +. Create the following `allow-n1-a-to-n2-b` network policy to allow pods across namespaces to communicate with each other. With this YAML, pods in the `project-a` that are labeled with `send-data` can communicate with pods in the `project-b` namespace that are labeled with `receive-data`. The namespaces must also be labeled to allow for communication. Save the YAML in the `allow-n1-a-to-n2-b` file: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-n1-a-to-n2-b +spec: + podSelector: + matchLabels: + app: receive-data <1> + policyTypes: + - Ingress + ingress: + - from: + - namespaceSelector: + matchLabels: + networking/namespace: n1 <2> + podSelector: + matchLabels: + app: send-data <3> +---- +<1> Apply the `app: receive-data` label to pods in the `project-b` namespace. +<2> Apply the `n1` label to the `project-a` namespace. +<3> Apply the `app: send-data` label to pods in the `project-a` namespace. + +. Apply the `allow-n1-a-to-n2-b` network policy to the `project-b` namespace by running the following command: ++ +[source,terminal] +---- +$ oc apply -f allow-n1-a-to-n2-b.yaml -n project-b +---- + +. Label the `project-a` namespace with the `networking/namespace=n1` label by entering the following command: ++ +[source,terminal] +---- +$ oc label namespace project-a networking/namespace=n1 --overwrite +---- + +. Label the `project-b` namespace with the `networking/namespace=n2` label by entering the following command: ++ +[source,terminal] +---- +$ oc label namespace project-b networking/namespace=n2 --overwrite +---- + +. If it is not already labeled, label the `busybox-pod` in `project-a` with the `send-data` label by entering the following command: ++ +[source,terminal] +---- +$ oc label pod busybox-pod-a app=send-data -n project-a +---- + +. If it is not already labeled, label the `test-pod` in `project-b` with the `receive-data` label by entering the following command: ++ +[source,terminal] +---- +$ oc label pod test-pod-b app=receive-data -n project-b --overwrite +---- + +.Verification + +. Obtain the IP addresses of pods in `project-b` by running the following command: ++ +[source,terminal] +---- +$ oc get pod -n project-b -o wide +---- ++ +.Example output ++ +[source,terminal] +---- +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +busybox-pod-b 1/1 Running 0 51m 10.132.0.39 ip-10-0-132-187.ec2.internal +test-pod-b 1/1 Running 0 51m 10.132.0.41 ip-10-0-132-187.ec2.internal +---- + +. Ensure that the `busybox-pod-a` pod in the `project-a` namespace can send data to the `test-pod-b` pod in the `project-b` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc exec -it busybox-pod-a -n project-a -- ping 10.132.0.41 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.41 (10.132.0.41): 56 data bytes +64 bytes from 10.132.0.41: seq=0 ttl=42 time=1.201 ms +64 bytes from 10.132.0.41: seq=1 ttl=42 time=0.640 ms +---- + +. Ensure that unlabeled pods cannot send and receive data by entering the following command. In this example, because the `test-pod-a` pod is not labeled with `send-data`, it cannot send data to the `test-pod-b` pod, even though that pod has the `receive-data` label. ++ +[source,terminal] +---- +$ oc exec -it test-pod-a -n project-a -- ping 10.132.0.41 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.41 (10.132.0.41): 56 data bytes +--- 10.132.0.41 ping statistics --- +2 packets transmitted, 0 packets received, 100% packet loss +---- diff --git a/modules/nw-networkpolicy-deny-all-allowed.adoc b/modules/nw-networkpolicy-deny-all-allowed.adoc index 7109e326a606..9fdd56b14635 100644 --- a/modules/nw-networkpolicy-deny-all-allowed.adoc +++ b/modules/nw-networkpolicy-deny-all-allowed.adoc @@ -3,6 +3,7 @@ // * networking/multiple_networks/configuring-multi-network-policy.adoc // * networking/network_security/network_policy/creating-network-policy.adoc // * microshift_networking/microshift-creating-network-policy.adoc +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc :name: network :role: admin diff --git a/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc b/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc new file mode 100644 index 000000000000..efad08743f75 --- /dev/null +++ b/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc @@ -0,0 +1,101 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-networkpolicy-deny-all-egress-network-policy_{context}"] += Creating a default deny all egress network policy + +Use the following procedure to create a `default-deny-all` network policy that isolates all pods for egress. + +[WARNING] +==== +Without configuring a `NetworkPolicy` custom resource (CR) that allows traffic communication, the following policy might cause communication problems across your cluster. +Creating a `default-deny-all` network policy that isolates pods for egress breaks pod-to-pod communication for ingress. This behavior is expected, and every connection allowed in the ingress direction must also allowlist connections in the egress direction. After creating a `default-deny-all` network policy, you should "Configure internet for egress pods" and "Enable pod-to-pod communication". +==== + +.Prerequisites + +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* You installed the OpenShift CLI (`oc`). +* You are logged in to the cluster with a user with admin privileges. +* You have configured an ingress network policy. +* You have created at least two projects in your cluster. +* You have created pods in your cluster. + +.Procedure + +. Create the following YAML that defines a `default-deny-all-egress` network policy to deny egress for all pods in the namespace. Save the YAML in the `default-deny-all-egress.yaml` file: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all-egress +spec: + podSelector: {} + egress: + - to: + ports: + - protocol: TCP + port: 53 <1> + - protocol: UDP + port: 53 <1> + policyTypes: + - Egress +---- +<1> Allows connections to port `53` on any IP to facilitate DNS lookups. + +. Apply the policy by entering the following command: ++ +[IMPORTANT] +==== +Do not apply this network policy to the `kube-system` namespace, as it can break cluster functionality. +==== ++ +[source,terminal] +---- +$ oc apply -f default-deny-all-egress.yaml -n project-a +---- + +. Because network policies are namespaced resources, you must create this network policy for each namespace. Apply the policy to other applicable namespaces by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f default-deny-all-egress.yaml -n project-b +---- ++ +With the application of the `default-deny-all-egress` network policy, pods in those namespaces cannot receive external traffic. + +.Verification + +. Test egress connection on a pod by entering the following command. If the network policy was successfully applied, then the pod is unable to reach the endpoint: ++ +[source,terminal] +---- +$ oc exec -it test-pod-b -n project-b -- nslookup google.com +---- ++ +.Example output ++ +[source,terminal] +---- +;; connection timed out; no servers could be reached +---- + +. Test ingress connection between pods in the `project-a` and `project-b` namespaces by entering the following command. Because the `default-deny-all-egress` network policy breaks pod-to-pod communication for ingress, pods should not longer be able to communicate. ++ +[source,terminal] +---- +$ oc exec -it busybox-pod-a -n project-a -- ping 10.132.0.44 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.44 (10.132.0.44): 56 data bytes +--- 10.132.0.44 ping statistics --- +3 packets transmitted, 0 packets received, 100% packet loss +---- \ No newline at end of file diff --git a/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc b/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc new file mode 100644 index 000000000000..e8507e76b577 --- /dev/null +++ b/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc @@ -0,0 +1,108 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-networkpolicy-enable-pod-pod-communication-egress_{context}"] += Enabling pod-to-pod communication + +After creating a `default-deny-all` network policy that isolates pods for egress, pod-to-pod communication is broken for ingress. To re-establish ingress communication for pods, you must create a complementary egress network policy that _mirrors_ the network policy that allowed for ingress pod-to-pod communication across namespaces. + +The following procedure shows you how to create a complementary egress network policy named `egress-allow-n1-a-to-n2-b`. The `egress-allow-n1-a-to-n2-b` network policy mirrors the the `allow-n1-a-to-n2-b` network policy that was created in "Creating a network policy for cross-namespace communication" and is applied to the opposite namespace that the `allow-n1-a-to-n2-b` network policy was applied to. Mirroring the `allow-n1-a-to-n2-b` network policy requires you to adjust the following fields of that network policy: + +* Change the `policyTypes` field to be an array that contains only `Egress`. +* Take the `spec.podSelector` field, and put it inside of a `spec.egress.to.podSelector` block. +* Remove the `ingress.from` section for your new egress policy, but copy the `ingress.from.podSelector` reference and make it the `spec.podSelector` of the egress policy. + +.Prerequisites + +* You have created the following `allow-n1-a-to-n2-b` ingress network policy: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-n1-a-to-n2-b +spec: + podSelector: + matchLabels: + app: receive-data + policyTypes: + - Ingress + ingress: + - from: + - namespaceSelector: + matchLabels: + networking/namespace: + podSelector: + matchLabels: + app: send-data +---- + +.Procedure + +. Create the following `egress-allow-n1-a-to-n2-b` network policy that mirrors the `allow-n1-a-to-n2-b` network policy: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-n1-a-to-n2-b-egress +spec: + podSelector: + matchLabels: + app: send-data + egress: + - to: + - namespaceSelector: + matchLabels: + networking/namespace: n2 + podSelector: + matchLabels: + app: receive-data + policyTypes: + - Egress +---- + +. Apply the `allow-n1-a-to-n2-b-egress` network policy to the `project-a` namespace by running the following command: ++ +[source,terminal] +---- +$ oc apply -f allow-n1-a-to-n2-b-egress.yaml -n project-a +---- + +.Verification + +. Obtain the IP addresses of pods in the `project-b` namespace by running the following command: ++ +[source,terminal] +---- +$ oc get pod -n project-a -o wide +---- ++ +.Example output ++ +[source,terminal] +---- +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +busybox-pod-b 1/1 Running 0 10m 10.132.0.42 ip-10-0-138-121.ec2.internal +test-pod-b 1/1 Running 0 10m 10.132.0.44 ip-10-0-138-121.ec2.internal +---- + +. Ensure that a pod in the `project-a` namespace can communicate with a pod in the `project-b` namespace. For example: ++ +[source,terminal] +---- +$ oc exec -it busybox-pod-a -n project-a -- ping 10.132.0.44 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.44 (10.132.0.44): 56 data bytes +64 bytes from 10.132.0.44: seq=0 ttl=42 time=1.129 ms +64 bytes from 10.132.0.44: seq=1 ttl=42 time=0.608 ms +---- \ No newline at end of file diff --git a/modules/nw-networkpolicy-multitenant-isolation-egress.adoc b/modules/nw-networkpolicy-multitenant-isolation-egress.adoc new file mode 100644 index 000000000000..829be5f2d296 --- /dev/null +++ b/modules/nw-networkpolicy-multitenant-isolation-egress.adoc @@ -0,0 +1,20 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: PROCEDURE +[id="nw-networkpolicy-multitenant-isolation-egress_{context}"] += Multitenant egress network policies + +By default, if no egress network policy is applied to a pod, the pod is not isolated for egress traffic. When a pod is not isolated for egress, it can send traffic freely to any destination. + +With an egress multitenant isolation network policy, cluster administrators can control outbound traffic from pods. When an egress network policy is applied to a pod, that pod becomes _isolated_ for egress, meaning that egress traffic is allowed only if it is permitted by at least one matching egress rule. + +Egress network policies help ensure that only authorized outbound traffic, such as communication with external services or specific namespaces, is allowed, depending on the configuration. + +[IMPORTANT] +==== +* Before configuring an egress network policy, cluster administrators should first configure ingress network policies. Attempting to configure both at the same time can make it difficult to determine which network policy is blocking traffic. + +* Egress network policies are harder to effectively implement than ingress network policies. Restricting outbound traffic might lead to unexpected issues. +==== \ No newline at end of file diff --git a/modules/nw-networkpolicy-pod-pod-communication.adoc b/modules/nw-networkpolicy-pod-pod-communication.adoc new file mode 100644 index 000000000000..a77e071a2c43 --- /dev/null +++ b/modules/nw-networkpolicy-pod-pod-communication.adoc @@ -0,0 +1,15 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: REFERENCE +[id="nw-networkpolicy-pod-pod-communication_{context}"] += Creating a pod-to-pod communication network policy + +After you have created the `deny-by-default` network policy, you can create a network policy that allows pods to communicate with each other. The following sections show you how to create three different network policies: + +* An `ingress-access` network policy, which allows specific pods to _receive_ traffic. +* An `allow-same-namespace` network policy, which allows pods within the same namespace to communicate with each other. +* An `allow-n1-a-to-n2-b` network policy, which allows pods across namespaces to communicate with each other. + +Choose the network policy that best suits your needs. \ No newline at end of file diff --git a/modules/nw-networkpolicy-same-namespace-communication.adoc b/modules/nw-networkpolicy-same-namespace-communication.adoc new file mode 100644 index 000000000000..449cb025764e --- /dev/null +++ b/modules/nw-networkpolicy-same-namespace-communication.adoc @@ -0,0 +1,73 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: REFERENCE +[id="nw-networkpolicy-same-namespace-communication_{context}"] += Creating a network policy for same namespace communication + +With the `deny-by-default` network policy in place, a second option to enable communication is to create a network policy that allows for same namespace communication using the following `allow-same-namespace` network policy. + +.Prerequisites + +* You have created the `deny-by-default` network policy and applied it to all necessary namespaces. + +.Procedure + +. Create the following `allow-same-namespace` network policy to allow pods within the same to communicate with each other. Save the YAML in the `allow-same-namespace` file: ++ +[source,yaml] +---- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-same-namespace +spec: + podSelector: {} + policyTypes: + - Ingress + ingress: + - from: + - podSelector: {} +---- + +. Apply the `allow-same-namespace` network policy to the `project-a` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc apply -f allow-same-namespace.yaml -n project-a +---- + +.Verification + +. Obtain the IP addresses of pods in `project-a` by running the following command: ++ +[source,terminal] +---- +$ oc get pod -n project-a -o wide +---- ++ +.Example output ++ +[source,terminal] +---- +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +busybox-pod-a 1/1 Running 0 44m 10.132.0.38 ip-10-0-132-187.ec2.internal +test-pod-a 1/1 Running 0 44m 10.132.0.40 ip-10-0-132-187.ec2.internal +---- + +. Ensure that communication can be made between pods in `project-a` by entering the following command: ++ +[source,terminal] +---- +$ oc exec -it busybox-pod-a -n project-a -- ping 10.132.0.40 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.40 (10.132.0.40): 56 data bytes +64 bytes from 10.132.0.40: seq=0 ttl=42 time=0.792 ms +64 bytes from 10.132.0.40: seq=1 ttl=42 time=0.533 ms +---- \ No newline at end of file diff --git a/modules/nw-policy-cluster-preparation.adoc b/modules/nw-policy-cluster-preparation.adoc new file mode 100644 index 000000000000..0b8f6d057af4 --- /dev/null +++ b/modules/nw-policy-cluster-preparation.adoc @@ -0,0 +1,137 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + + + +:_mod-docs-content-type: PROCEDURE +[id="nw-policy-cluster-preparation_{context}"] += Preparing your cluster for multitenant isolation with ingress and egress network policies + +The following procedure creates the projects and pods that are used throughout the rest of this chapter. + +.Prerequisites + +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* You have installed the OpenShift CLI (`oc`). +* You are logged in as a user with cluster admin privileges. + +.Procedure + +. Create the `project-a` namespace by entering the following command: ++ +[source,terminal] +---- +$ oc new-project project-a +---- + +. Create the project-b namespace by entering the following command: ++ +[source,terminal] +---- +$ oc new-project project-b +---- + +. Create the following `busybox-pod-a` pod in the `project-a` namespace: ++ +[source,terminal] +---- +cat < +test-pod-a 1/1 Running 0 2m37s 10.132.0.40 ip-10-0-132-187.ec2.internal +---- + +. Obtain the IP addresses of pods in `project-b` by running the following command: ++ +[source,terminal] +---- +$ oc get pod -n project-b -o wide +---- ++ +.Example output ++ +[source,terminal] +---- +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +busybox-pod-b 1/1 Running 0 2m47s 10.132.0.39 ip-10-0-132-187.ec2.internal +test-pod-b 1/1 Running 0 2m38s 10.132.0.41 ip-10-0-132-187.ec2.internal +---- + +. Attempt to establish a connection between pods in `project-a` by running the following command: ++ +[source,terminal] +---- +$ oc exec -it test-pod-a -n project-a -- ping 10.132.0.38 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.143.0.38 (10.143.0.38): 56 data bytes +--- 10.143.0.38 ping statistics --- +3 packets transmitted, 0 packets received, 100% packet loss +---- ++ +This behavior is intended because of the `default-deny-all` network policy. + +. Attempt to establish a connection between pods in `project-a` and `project-b` by running the following command: ++ +[source,terminal] +---- +$ oc exec -it test-pod-a -n project-a -- ping 10.132.0.41 +---- ++ +.Example output ++ +[source,terminal] +---- +PING 10.132.0.41 (10.132.0.41): 56 data bytes +--- 10.132.0.41 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss +---- ++ +This behavior is intended because of the `default-deny-all` network policy. \ No newline at end of file diff --git a/modules/nw-policy-multitenant-isolation-ingress.adoc b/modules/nw-policy-multitenant-isolation-ingress.adoc new file mode 100644 index 000000000000..bc5afeaf5939 --- /dev/null +++ b/modules/nw-policy-multitenant-isolation-ingress.adoc @@ -0,0 +1,9 @@ +// Module included in the following assemblies: +// +// * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc + +:_mod-docs-content-type: CONCEPT +[id="nw-policy-multitenant-isolation-ingress_{context}"] += Multitenant ingress network policies + +Configuring ingress network policies can help improve the security of your deployment by isolating pods from unauthorized incoming traffic. The following examples show you how to set up a multitenant ingress network policy with different network policies that allow, or restrict, communication between namespaces or pods. Use these examples to configure your deployment as necessary. diff --git a/networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc b/networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc new file mode 100644 index 000000000000..8ca707078b93 --- /dev/null +++ b/networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc @@ -0,0 +1,31 @@ +:_mod-docs-content-type: ASSEMBLY +[id="nw-networkpolicy-full-multitenant-isolation"] += Configuring full multitenant isolation with ingress and egress network policies +include::_attributes/common-attributes.adoc[] +:context: multitenant-network-policy + +toc::[] + +As a cluster administrator, you can configure ingress and egress network policies to enforce full multitenant isolation between projects. This ensures that pods can only communicate with explicitly allowed services or destinations, which helps improve the security of your deployment. + +[NOTE] +==== +Configuring network policies as described in this section provides network isolation similar to the multitenant mode of OpenShift SDN in previous versions of {product-title}. +==== + +//preparation +include::modules/nw-policy-cluster-preparation.adoc[leveloffset=+1] + +//ingress +include::modules/nw-policy-multitenant-isolation-ingress.adoc[leveloffset=+1] +include::modules/nw-policy-default-deny-ingress.adoc[leveloffset=+2] +include::modules/nw-networkpolicy-pod-pod-communication.adoc[leveloffset=+2] +include::modules/nw-networkpolicy-allow-internet.adoc[leveloffset=+3] +include::modules/nw-networkpolicy-same-namespace-communication.adoc[leveloffset=+3] +include::modules/nw-networkpolicy-cross-namespace-communication.adoc[leveloffset=+3] + +//egress +include::modules/nw-networkpolicy-multitenant-isolation-egress.adoc[leveloffset=+1] +include::modules/nw-networkpolicy-deny-all-egress-network-policy.adoc[leveloffset=+2] +include::modules/nw-networkpolicy-configuring-internet-egress-pods.adoc[leveloffset=+2] +include::modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc[leveloffset=+2] \ No newline at end of file From a7ea4d5111671ddfe2e78d0ec8a70ba41ee454e5 Mon Sep 17 00:00:00 2001 From: Steven Smith Date: Tue, 16 Sep 2025 14:15:57 -0400 Subject: [PATCH 2/2] Updates egress netpol docs --- ...licy-allow-application-all-namespaces.adoc | 2 +- ...llow-application-particular-namespace.adoc | 2 +- ...-networkpolicy-allow-external-clients.adoc | 2 +- modules/nw-networkpolicy-allow-internet.adoc | 12 ++++---- ...cy-configuring-ingress-new-deployment.adoc | 28 ++++++++++--------- ...licy-configuring-internet-egress-pods.adoc | 15 +++------- modules/nw-networkpolicy-create-cli.adoc | 2 +- ...kpolicy-cross-namespace-communication.adoc | 6 ++-- modules/nw-networkpolicy-delete-cli.adoc | 2 +- .../nw-networkpolicy-deny-all-allowed.adoc | 4 +-- ...policy-deny-all-egress-network-policy.adoc | 6 ++-- modules/nw-networkpolicy-edit.adoc | 2 +- ...y-enable-pod-pod-communication-egress.adoc | 12 ++++---- ...w-networkpolicy-multitenant-isolation.adoc | 2 +- ...rkpolicy-same-namespace-communication.adoc | 2 +- modules/nw-policy-cluster-preparation.adoc | 2 +- modules/nw-policy-default-deny-ingress.adoc | 4 +-- 17 files changed, 50 insertions(+), 55 deletions(-) diff --git a/modules/nw-networkpolicy-allow-application-all-namespaces.adoc b/modules/nw-networkpolicy-allow-application-all-namespaces.adoc index 93f9edcf301d..113031748e7c 100644 --- a/modules/nw-networkpolicy-allow-application-all-namespaces.adoc +++ b/modules/nw-networkpolicy-allow-application-all-namespaces.adoc @@ -27,7 +27,7 @@ Follow this procedure to configure a policy that allows traffic from all pods in .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-allow-application-particular-namespace.adoc b/modules/nw-networkpolicy-allow-application-particular-namespace.adoc index 6e7fb7755364..ef7f11993068 100644 --- a/modules/nw-networkpolicy-allow-application-particular-namespace.adoc +++ b/modules/nw-networkpolicy-allow-application-particular-namespace.adoc @@ -30,7 +30,7 @@ Follow this procedure to configure a policy that allows traffic to a pod with th .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-allow-external-clients.adoc b/modules/nw-networkpolicy-allow-external-clients.adoc index c9ef9e7a2fbc..dd5144b84e48 100644 --- a/modules/nw-networkpolicy-allow-external-clients.adoc +++ b/modules/nw-networkpolicy-allow-external-clients.adoc @@ -34,7 +34,7 @@ Follow this procedure to configure a policy that allows external service from th .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-allow-internet.adoc b/modules/nw-networkpolicy-allow-internet.adoc index 738e923c6866..01a11215a9c3 100644 --- a/modules/nw-networkpolicy-allow-internet.adoc +++ b/modules/nw-networkpolicy-allow-internet.adoc @@ -6,11 +6,11 @@ [id="nw-networkpolicy-allow-ingress_{context}"] = Creating an allow ingress access network policy -With the `deny-by-default` network policy in place, no pods can talk to each other or receive traffic from external sources. One option to enable communication is to allow some pods to receive traffic. To do so, you can create the following `ingress-access` network policy. With this network policy, pods with the `networking/allow-ingress-access=true` label can receive network traffic. +With the `deny-by-default` network policy that denies both ingress and egress traffic in place, no pods can talk to each other or receive traffic from external sources. One option to enable communication is to allow some pods to receive traffic. To do so, you can create the following `ingress-access` network policy. With this network policy, pods with the `networking/allow-ingress-access=true` label can receive network traffic. .Prerequisites -* You have created the `deny-by-default` network policy and applied it to the necessary namespaces. +* You have created the `deny-by-default` network policy and applied it to the necessary namespaces. The policy denies ingress traffic to pods in the project. .Procedure @@ -31,7 +31,7 @@ spec: ingress: - {} ---- -<1> Apply this label to pods to enable the pod to receive traffic from outside sources. +<1> Apply this label to pods to enable the pods to receive traffic from outside sources. . Apply the network policy to the `project-a` namespace by entering the following command: + @@ -74,11 +74,11 @@ busybox-pod-a 1/1 Running 0 13m 10.132.0.38 ip-10-0-132-187 test-pod-a 1/1 Running 0 13m 10.132.0.40 ip-10-0-132-187.ec2.internal ---- -. Ensure that pods with the `networking/allow-ingress-access=true` label can receive traffic by entering the following command. If you followed these instructions, the `busybox-pod-a` pod in `project-a` can receive traffic from another pod. For example: +. Ensure that pods with the `networking/allow-ingress-access=true` label can receive two ICMP packets by entering the following command. If you followed these instructions, the `busybox-pod-a` pod in `project-a` can receive traffic from another pod. For example: + [source,terminal] ---- -$ oc exec -it test-pod-b -n project-b -- ping 10.132.0.44 +$ oc exec -it test-pod-b -n project-b -- ping -c 2 10.132.0.44 ---- + .Example output @@ -94,7 +94,7 @@ PING 10.132.0.44 (10.132.0.44): 56 data bytes + [source,terminal] ---- -$ oc exec -it busybox-pod-a -n project-a -- ping 10.132.0.40 +$ oc exec -it busybox-pod-a -n project-a -- ping -c 2 10.132.0.40 ---- + .Example output diff --git a/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc b/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc index 6bf19a74cbf1..3b001ff03969 100644 --- a/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc +++ b/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc @@ -59,14 +59,15 @@ kind: NetworkPolicy metadata: name: allow-ingress-from-new spec: - podSelector: {} - policyTypes: - - Ingress ingress: - from: - - podSelector: + - namespaceSelector: {} + podSelector: matchLabels: networking/allow-all-connections: "true" + podSelector: {} + policyTypes: + - Ingress ---- .. Apply the network policy by entering the following command: @@ -83,23 +84,24 @@ $ oc apply -f allow-ingress-from-new.yaml -n project-a apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: - name: allow-ingress-to-new + name: allow-ingress-from-new spec: - podSelector: - matchLabels: - networking/allow-all-connections: "true" - policyTypes: - - Ingress ingress: - from: - - podSelector: {} + - namespaceSelector: {} + podSelector: + matchLabels: + networking/allow-all-connections: "true" + podSelector: {} + policyTypes: + - Ingress ---- .. Apply the network policy by entering the following command: + [source,terminal] ---- -$ oc apply -f allow-ingress-tp-new.yaml -n project-a +$ oc apply -f allow-ingress-to-new.yaml -n project-a ---- .. Apply the `networking/allow-all-connections=true` to pods in `project-a` that you want to be able to communicate with pods in `project-c` by running the following command: @@ -160,7 +162,7 @@ spec: + [source,terminal] ---- -$ oc apply -f allow-ingress-tp-new.yaml -n project-c +$ oc apply -f allow-ingress-to-new.yaml -n project-c ---- .. Apply the `networking/allow-all-connections=true` to pods in `project-c` that you want to be able to communicate with pods in `project-a` by running the following command: diff --git a/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc b/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc index cac6f87523c8..972fafc861e5 100644 --- a/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc +++ b/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc @@ -3,10 +3,10 @@ // * networking/network_security/network_policy/nw-networkpolicy-full-multitenant-isolation.adoc :_mod-docs-content-type: PROCEDURE -[id="nw-networkpolicy-configuring-internet-egress-pods_{context}"] -= Configuring internet egress for pods +[id="nw-networkpolicy-configuring-external-egress-pods_{context}"] += Configuring external egress for pods -With the deny all egress network policy created in a namespace, pods within that namespace are made incapable of reaching _out_ to the internet. In most cases, at least some pods within a namespace need to reach external traffic. +With the deny all egress network policy created in a namespace, pods within that namespace are made incapable of reaching _out_ to the internet. In most cases, at least some pods within a namespace need to reach external destinations. The following procedure shows you how to designate labels to pods that require internet egress. @@ -41,13 +41,6 @@ spec: $ oc apply -f internet-egress.yaml -n project-a ---- -. Apply the network policy to the `project-b` namespace by entering the following command: -+ -[source,terminal] ----- -$ oc apply -f internet-egress.yaml -n project-b ----- - . Apply the `networking/allow-internet-egress=true` label to pods that require egress by entering the following command: + [source,terminal] @@ -61,7 +54,7 @@ $ oc label pod busybox-pod-a networking/allow-internet-egress=true -n project-a + [source,terminal] ---- -$ oc exec -it -n project-a -- nslookup google.com +$ oc exec -it busybox-pod-a -n project-a -- nslookup google.com ---- + .Example output diff --git a/modules/nw-networkpolicy-create-cli.adoc b/modules/nw-networkpolicy-create-cli.adoc index c4d587c5ca78..8b89e56a1d3e 100644 --- a/modules/nw-networkpolicy-create-cli.adoc +++ b/modules/nw-networkpolicy-create-cli.adoc @@ -28,7 +28,7 @@ endif::multi,microshift[] .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-cross-namespace-communication.adoc b/modules/nw-networkpolicy-cross-namespace-communication.adoc index d9178f105aee..d3c0e2c5fdba 100644 --- a/modules/nw-networkpolicy-cross-namespace-communication.adoc +++ b/modules/nw-networkpolicy-cross-namespace-communication.adoc @@ -52,21 +52,21 @@ $ oc apply -f allow-n1-a-to-n2-b.yaml -n project-b + [source,terminal] ---- -$ oc label namespace project-a networking/namespace=n1 --overwrite +$ oc label namespace project-a networking/namespace=n1 ---- . Label the `project-b` namespace with the `networking/namespace=n2` label by entering the following command: + [source,terminal] ---- -$ oc label namespace project-b networking/namespace=n2 --overwrite +$ oc label namespace project-b networking/namespace=n2 ---- . If it is not already labeled, label the `busybox-pod` in `project-a` with the `send-data` label by entering the following command: + [source,terminal] ---- -$ oc label pod busybox-pod-a app=send-data -n project-a +$ oc label pod busybox-pod-a app=send-data -n project-a --overwrite ---- . If it is not already labeled, label the `test-pod` in `project-b` with the `receive-data` label by entering the following command: diff --git a/modules/nw-networkpolicy-delete-cli.adoc b/modules/nw-networkpolicy-delete-cli.adoc index 0672e54747d8..3fb4f373cc68 100644 --- a/modules/nw-networkpolicy-delete-cli.adoc +++ b/modules/nw-networkpolicy-delete-cli.adoc @@ -27,7 +27,7 @@ endif::multi,microshift[] .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-deny-all-allowed.adoc b/modules/nw-networkpolicy-deny-all-allowed.adoc index 9fdd56b14635..604855ef8e8e 100644 --- a/modules/nw-networkpolicy-deny-all-allowed.adoc +++ b/modules/nw-networkpolicy-deny-all-allowed.adoc @@ -21,12 +21,12 @@ This policy blocks all cross-pod networking other than network traffic allowed b [WARNING] ==== -Without configuring a `NetworkPolicy` custom resource (CR) that allows traffic communication, the following policy might cause communication problems across your cluster. +Without configuring a network policy that allows traffic communication, the following policy might cause communication problems across your cluster. ==== .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc b/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc index efad08743f75..edf56663b942 100644 --- a/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc +++ b/modules/nw-networkpolicy-deny-all-egress-network-policy.adoc @@ -10,13 +10,13 @@ Use the following procedure to create a `default-deny-all` network policy that i [WARNING] ==== -Without configuring a `NetworkPolicy` custom resource (CR) that allows traffic communication, the following policy might cause communication problems across your cluster. +Without configuring a network policy that allows traffic communication, the following policy might cause communication problems across your cluster. Creating a `default-deny-all` network policy that isolates pods for egress breaks pod-to-pod communication for ingress. This behavior is expected, and every connection allowed in the ingress direction must also allowlist connections in the egress direction. After creating a `default-deny-all` network policy, you should "Configure internet for egress pods" and "Enable pod-to-pod communication". ==== .Prerequisites -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. * You installed the OpenShift CLI (`oc`). * You are logged in to the cluster with a user with admin privileges. * You have configured an ingress network policy. @@ -84,7 +84,7 @@ $ oc exec -it test-pod-b -n project-b -- nslookup google.com ;; connection timed out; no servers could be reached ---- -. Test ingress connection between pods in the `project-a` and `project-b` namespaces by entering the following command. Because the `default-deny-all-egress` network policy breaks pod-to-pod communication for ingress, pods should not longer be able to communicate. +. Test ingress connection between pods in the `project-a` and `project-b` namespaces by entering the following command. Because the `default-deny-all-egress` network policy breaks pod-to-pod communication for egress, pods should not longer be able to communicate. + [source,terminal] ---- diff --git a/modules/nw-networkpolicy-edit.adoc b/modules/nw-networkpolicy-edit.adoc index 4aa1ce0df757..d6d4bfc670b3 100644 --- a/modules/nw-networkpolicy-edit.adoc +++ b/modules/nw-networkpolicy-edit.adoc @@ -26,7 +26,7 @@ endif::multi,microshift[] .Prerequisites ifndef::microshift[] -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. endif::microshift[] * You installed the OpenShift CLI (`oc`). ifndef::microshift[] diff --git a/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc b/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc index e8507e76b577..05c0c98d1575 100644 --- a/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc +++ b/modules/nw-networkpolicy-enable-pod-pod-communication-egress.adoc @@ -6,7 +6,7 @@ [id="nw-networkpolicy-enable-pod-pod-communication-egress_{context}"] = Enabling pod-to-pod communication -After creating a `default-deny-all` network policy that isolates pods for egress, pod-to-pod communication is broken for ingress. To re-establish ingress communication for pods, you must create a complementary egress network policy that _mirrors_ the network policy that allowed for ingress pod-to-pod communication across namespaces. +After creating a egress `default-deny-all` network policy that isolates pods for egress, pod-to-pod communication is broken for ingress in the other namespace. To re-establish ingress communication for pods, you must create a complementary egress network policy that _mirrors_ the network policy that allowed for ingress pod-to-pod communication across namespaces. The following procedure shows you how to create a complementary egress network policy named `egress-allow-n1-a-to-n2-b`. The `egress-allow-n1-a-to-n2-b` network policy mirrors the the `allow-n1-a-to-n2-b` network policy that was created in "Creating a network policy for cross-namespace communication" and is applied to the opposite namespace that the `allow-n1-a-to-n2-b` network policy was applied to. Mirroring the `allow-n1-a-to-n2-b` network policy requires you to adjust the following fields of that network policy: @@ -16,7 +16,7 @@ The following procedure shows you how to create a complementary egress network p .Prerequisites -* You have created the following `allow-n1-a-to-n2-b` ingress network policy: +* You have created the following `allow-n1-a-to-n2-b` ingress network policy in the `project-b` namespace: + [source,yaml] ---- @@ -34,7 +34,7 @@ spec: - from: - namespaceSelector: matchLabels: - networking/namespace: + networking/namespace: n1 podSelector: matchLabels: app: send-data @@ -49,7 +49,7 @@ spec: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: - name: allow-n1-a-to-n2-b-egress + name: egress-allow-n1-a-to-n2-b spec: podSelector: matchLabels: @@ -70,7 +70,7 @@ spec: + [source,terminal] ---- -$ oc apply -f allow-n1-a-to-n2-b-egress.yaml -n project-a +$ oc apply -f egress-allow-n1-a-to-n2-b.yaml -n project-a ---- .Verification @@ -79,7 +79,7 @@ $ oc apply -f allow-n1-a-to-n2-b-egress.yaml -n project-a + [source,terminal] ---- -$ oc get pod -n project-a -o wide +$ oc get pod -n project-b -o wide ---- + .Example output diff --git a/modules/nw-networkpolicy-multitenant-isolation.adoc b/modules/nw-networkpolicy-multitenant-isolation.adoc index 7c8f725c78bb..1bb68d8d88df 100644 --- a/modules/nw-networkpolicy-multitenant-isolation.adoc +++ b/modules/nw-networkpolicy-multitenant-isolation.adoc @@ -11,7 +11,7 @@ project namespaces. .Prerequisites -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. * You installed the OpenShift CLI (`oc`). * You are logged in to the cluster with a user with `admin` privileges. diff --git a/modules/nw-networkpolicy-same-namespace-communication.adoc b/modules/nw-networkpolicy-same-namespace-communication.adoc index 449cb025764e..5ff61d85061b 100644 --- a/modules/nw-networkpolicy-same-namespace-communication.adoc +++ b/modules/nw-networkpolicy-same-namespace-communication.adoc @@ -6,7 +6,7 @@ [id="nw-networkpolicy-same-namespace-communication_{context}"] = Creating a network policy for same namespace communication -With the `deny-by-default` network policy in place, a second option to enable communication is to create a network policy that allows for same namespace communication using the following `allow-same-namespace` network policy. +With the `deny-by-default` network policy in place, a second option to enable pod to pod communication within namespace is to create a network policy that allows for same namespace communication using the following `allow-same-namespace` network policy. .Prerequisites diff --git a/modules/nw-policy-cluster-preparation.adoc b/modules/nw-policy-cluster-preparation.adoc index 0b8f6d057af4..b7ebe38bfc56 100644 --- a/modules/nw-policy-cluster-preparation.adoc +++ b/modules/nw-policy-cluster-preparation.adoc @@ -12,7 +12,7 @@ The following procedure creates the projects and pods that are used throughout t .Prerequisites -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. * You have installed the OpenShift CLI (`oc`). * You are logged in as a user with cluster admin privileges. diff --git a/modules/nw-policy-default-deny-ingress.adoc b/modules/nw-policy-default-deny-ingress.adoc index 4afcb34cfd45..0000417f13c6 100644 --- a/modules/nw-policy-default-deny-ingress.adoc +++ b/modules/nw-policy-default-deny-ingress.adoc @@ -10,12 +10,12 @@ The following `default-deny-all` network policy blocks all cross-pod networking [WARNING] ==== -Without configuring a `NetworkPolicy` custom resource (CR) that allows traffic communication, the following policy might cause communication problems across your cluster. +Without configuring a network policy that allows traffic communication, the following policy might cause communication problems across your cluster. ==== .Prerequisites -* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. +* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin. * You have installed the OpenShift CLI (`oc`). * You are logged in as a user with cluster admin privileges. * You have created at least two namespaces. The following examples use `project-a` and `project-b` namespaces.