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-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 new file mode 100644 index 000000000000..01a11215a9c3 --- /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 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. The policy denies ingress traffic to pods in the project. + +.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 pods 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 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 -c 2 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 -c 2 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..3b001ff03969 --- /dev/null +++ b/modules/nw-networkpolicy-configuring-ingress-new-deployment.adoc @@ -0,0 +1,173 @@ +// 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-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: ++ +[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..972fafc861e5 --- /dev/null +++ b/modules/nw-networkpolicy-configuring-internet-egress-pods.adoc @@ -0,0 +1,68 @@ +// 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-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 destinations. + +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 `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 busybox-pod-a -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-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 new file mode 100644 index 000000000000..d3c0e2c5fdba --- /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 +---- + +. 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 +---- + +. 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 --overwrite +---- + +. 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-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 7109e326a606..604855ef8e8e 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 @@ -20,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 new file mode 100644 index 000000000000..edf56663b942 --- /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 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. +* 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 egress, 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-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 new file mode 100644 index 000000000000..05c0c98d1575 --- /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 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: + +* 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 in the `project-b` namespace: ++ +[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: n1 + 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: egress-allow-n1-a-to-n2-b +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 egress-allow-n1-a-to-n2-b.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-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 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-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-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..5ff61d85061b --- /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 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 + +* 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..b7ebe38bfc56 --- /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. +* 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