diff --git a/modules/nw-egress-firewall-about.adoc b/modules/nw-egress-firewall-about.adoc index c05780ba51eb..ce9b8d07cef8 100644 --- a/modules/nw-egress-firewall-about.adoc +++ b/modules/nw-egress-firewall-about.adoc @@ -40,14 +40,13 @@ An egress firewall has the following limitations: + The following example illustrates the order of the egress firewall rules necessary to ensure API server access: + -.`EgressFirewall` API server access example [source,yaml,subs="attributes+"] ---- apiVersion: k8s.ovn.org/v1 kind: EgressFirewall metadata: name: default - namespace: <1> + namespace: spec: egress: - to: diff --git a/modules/nw-egressnetworkpolicy-about.adoc b/modules/nw-egressnetworkpolicy-about.adoc deleted file mode 100644 index 410115ac07c1..000000000000 --- a/modules/nw-egressnetworkpolicy-about.adoc +++ /dev/null @@ -1,75 +0,0 @@ -// Module included in the following assemblies: -// -// * networking/openshift_sdn/configuring-egress-firewall.adoc - -:_mod-docs-content-type: CONCEPT -[id="nw-egressnetworkpolicy-about_{context}"] -= How an EgressNetworkPolicy custom resource works in a project - -As a cluster administrator, you can use an _egress firewall_ to -limit the external hosts that some or all pods can access from within the cluster. You configure an egress firewall policy by creating an `EgressNetworkPolicy` custom resource (CR). - -An egress firewall supports the following scenarios: - -- A pod can only connect to internal hosts and cannot start connections to -the public internet. -- A pod can only connect to the public internet and cannot start connections -to internal hosts that are outside the {product-title} cluster. -- A pod cannot reach specified internal subnets or hosts outside the {product-title} cluster. -- A pod can only connect to specific external hosts. - -For example, you can allow one project access to a specified IP range but deny the same access to a different project. Or you can restrict application developers from updating from Python pip mirrors, and force updates to come only from approved sources. - -In your `EgressNetworkPolicy` CR you can match network traffic that meets any of the following criteria: - -- An IP address range in CIDR format -- A DNS name that resolves to an IP address - -[id="limitations-of-an-egress-firewall_{context}"] -== Limitations of an EgressNetworkPolicy CR - -An egress firewall has the following limitations: - -* No project can have more than one `EgressNetworkPolicy` CR. The creation of more than one `EgressNetworkPolicy` CR is allowed, however; it should not be done. When you create more than one custom resource, you receive the following message: `dropping all rules`. In actuality, all external traffic is dropped, which can cause security risks for your organization. - -* You must have OpenShift SDN configured to use either the network policy or multitenant mode to configure an egress firewall. If you use network policy mode, an egress firewall is compatible with only one policy per namespace and will not work with projects that share a network, such as global projects. - -* A maximum of one `EgressNetworkPolicy` CR with a maximum of 1,000 rules can be defined per project. - -* The `default` project cannot use an egress firewall. - -* When using the OpenShift SDN network plugin in multitenant mode, the following limitations apply: - - - Global projects cannot use an egress firewall. You can make a project global by using the `oc adm pod-network make-projects-global` command. - - - Projects merged by using the `oc adm pod-network join-projects` command cannot use an egress firewall in any of the joined projects. - -* If you create a selectorless service and manually define endpoints or `EndpointSlices` that point to external IPs, traffic to the service IP might still be allowed, even if your `EgressNetworkPolicy` is configured to deny all egress traffic. This occurs because OpenShift SDN does not fully enforce egress network policies for these external endpoints. Consequently, this might result in unexpected access to external services. - -* Egress firewall does not apply to the host network namespace. Pods with host networking enabled are unaffected by egress firewall rules. - -* Egress firewall rules do not apply to traffic that goes through routers. Any user with permission to create a Route CR object can bypass egress firewall policy rules by creating a route that points to a forbidden destination. - -Violating any of these restrictions results in a broken egress firewall for the project. As a result, all external network traffic drops, which can cause security risks for your organization. - -You can create an Egress Firewall resource in the `kube-node-lease`, `kube-public`, `kube-system`, `openshift` and `openshift-` projects. - -[id="policy-rule-order-sdn_{context}"] -== Matching order for EgressNetworkPolicy CR rules - -The OVN-Kubernetes network plugin evaluates egress firewall policy rules based on the first-to-last order of how you defined the rules. The first rule that matches an egress connection from a pod applies. The plugin ignores any subsequent rules for that connection. - -[id="domain-name-server-resolution-sdn_{context}"] -== How Domain Name Server (DNS) resolution works - -If you use DNS names in any of your egress firewall policy rules, proper resolution of the domain names is subject to the following restrictions: - -* Domain name updates are polled based on a time-to-live (TTL) duration. By default, the duration is 30 seconds. When the egress firewall controller queries the local name servers for a domain name, if the response includes a TTL that is less than 30 seconds, the controller sets the duration to the returned value. If the TTL in the response is greater than 30 minutes, the controller sets the duration to 30 minutes. If the TTL is between 30 seconds and 30 minutes, the controller ignores the value and sets the duration to 30 seconds. - -* The pod must resolve the domain from the same local name servers when necessary. Otherwise the IP addresses for the domain known by the egress firewall controller and the pod can be different. If the IP addresses for a hostname differ, consistent enforcement of the egress firewall does not apply. - -* Because the egress firewall controller and pods asynchronously poll the same local name server, the pod might obtain the updated IP address before the egress controller does, which causes a race condition. Due to this current limitation, domain name usage in `EgressNetworkPolicy` CR is only recommended for domains with infrequent IP address changes. - -* Using DNS names in your `EgressNetworkPolicy` CR does not affect local DNS resolution through CoreDNS. -+ -However, if your policy uses domain names, and an external DNS server handles DNS resolution for an affected pod, you must include egress firewall rules that permit access to the IP addresses of your DNS server. diff --git a/modules/nw-egressnetworkpolicy-create.adoc b/modules/nw-egressnetworkpolicy-create.adoc deleted file mode 100644 index a3453c11dd72..000000000000 --- a/modules/nw-egressnetworkpolicy-create.adoc +++ /dev/null @@ -1,37 +0,0 @@ -// Module included in the following assemblies: -// -// * networking/network_security/configuring-egress-firewall-ovn.adoc - -:_mod-docs-content-type: PROCEDURE -[id="nw-networkpolicy-create_{context}"] -= Creating an EgressNetworkPolicy custom resource (CR) - -As a cluster administrator, you can create an `EgressNetworkPolicy` CR for a project. - -[IMPORTANT] -==== -If the project already has an `EgressNetworkPolicy` object defined, you must edit the existing policy to make changes to the egress firewall rules. -==== - -.Prerequisites - -* A cluster that uses the OpenShift SDN network plugin. -* Install the OpenShift CLI (`oc`). -* You must log in to the cluster as a cluster administrator. - -.Procedure - -. Create a policy rule: -.. Create a `.yaml` file where `` describes the egress policy rules. -.. Define the `EgressNetworkPolicy` in the file. - -. Create the policy object by entering the following command. Replace `` with the name of the policy and `` with the project that the rule applies to. -+ -[source,terminal] ----- -$ oc create -f .yaml -n ----- -+ -Successful output lists the `egressnetworkpolicy.network.openshift.io/v1` name and the `created` status. - -. Optional: Save the `.yaml` file so that you can make changes later. diff --git a/modules/nw-egressnetworkpolicy-delete.adoc b/modules/nw-egressnetworkpolicy-delete.adoc deleted file mode 100644 index 043ac1899091..000000000000 --- a/modules/nw-egressnetworkpolicy-delete.adoc +++ /dev/null @@ -1,35 +0,0 @@ -// Module included in the following assemblies: -// -// * networking/openshift_sdn/removing-egress-firewall.adoc - -:_mod-docs-content-type: PROCEDURE -[id="nw-egressnetworkpolicy-delete_{context}"] -= Removing an EgressNetworkPolicy custom resource (CR) - -As a cluster administrator, you can remove an egress firewall from a project. - -.Prerequisites - -* A cluster using the OpenShift SDN network plugin. -* Install the OpenShift CLI (`oc`). -* You must log in to the cluster as a cluster administrator. - -.Procedure - -. Find the name of the `EgressNetworkPolicy` CR for the project. -+ -[source,terminal,subs="attributes+"] ----- -$ oc get -n egressnetworkpolicy ----- -+ -Replace `` with the name of the project. - -. Enter the following command to delete the `EgressNetworkPolicy` CR. -+ -[source,terminal,subs="attributes+"] ----- -$ oc delete -n egressnetworkpolicy ----- -+ -Replace `` with the name of the project and `` with the name of the object. diff --git a/modules/nw-egressnetworkpolicy-edit.adoc b/modules/nw-egressnetworkpolicy-edit.adoc deleted file mode 100644 index ee1e82a092fc..000000000000 --- a/modules/nw-egressnetworkpolicy-edit.adoc +++ /dev/null @@ -1,44 +0,0 @@ -// Module included in the following assemblies: -// -// * networking/openshift_sdn/editing-egress-firewall.adoc - -:_mod-docs-content-type: PROCEDURE -[id="nw-egressnetworkpolicy-edit_{context}"] -= Editing an EgressNetworkPolicy custom resource (CR) - -As a cluster administrator, you can update the egress firewall for a project. - -.Prerequisites - -* A cluster using the OpenShift SDN network plugin. -* Install the OpenShift CLI (`oc`). -* You must log in to the cluster as a cluster administrator. - -.Procedure - -. Find the name of the `EgressNetworkPolicy` CR for the project. -+ -[source,terminal,subs="attributes+"] ----- -$ oc get -n egressnetworkpolicy ----- -+ -Replace `` with the name of the project. - -. Optional: If you did not save a copy of the `EgressNetworkPolicy` CR when you created the egress firewall, enter the following command to create a copy. -+ -[source,terminal,subs="attributes+"] ----- -$ oc get -n egressnetworkpolicy -o yaml > .yaml ----- -+ -Replace `` with the name of the project. Replace `` with the name of the object. Replace `` with the name of the file to save the YAML to. - -. After making changes to the policy rules, enter the following command to replace the `EgressNetworkPolicy` CR. -+ -[source,terminal] ----- -$ oc replace -f .yaml ----- -+ -Replace `` with the name of the file containing the updated `EgressNetworkPolicy` CR. diff --git a/modules/nw-egressnetworkpolicy-view.adoc b/modules/nw-egressnetworkpolicy-view.adoc deleted file mode 100644 index 94d132c471a5..000000000000 --- a/modules/nw-egressnetworkpolicy-view.adoc +++ /dev/null @@ -1,44 +0,0 @@ -// Module included in the following assemblies: -// -// * networking/openshift_sdn/configuring-egress-firewall.adoc - -:_mod-docs-content-type: PROCEDURE -[id="nw-egressnetworkpolicy-view_{context}"] -= Viewing an EgressNetworkPolicy custom resource (CR) - -You can view an `EgressNetworkPolicy` CR in your cluster. - -.Prerequisites - -* A cluster using the OpenShift SDN network plugin. -* Install the OpenShift Command-line Interface (CLI), commonly known as `oc`. -* You must log in to the cluster. - -.Procedure - -. Optional: To view the names of the `EgressNetworkPolicy` CRs defined in your cluster, enter the following command: -+ -[source,terminal,subs="attributes"] ----- -$ oc get egressnetworkpolicy --all-namespaces ----- - -. To inspect a policy, enter the following command. Replace `` with the name of the policy to inspect. -+ -[source,terminal,subs="attributes+"] ----- -$ oc describe egressnetworkpolicy ----- -+ -[source,terminal] -.Example output ----- -Name: default -Namespace: project1 -Created: 20 minutes ago -Labels: -Annotations: -Rule: Allow to 1.2.3.0/24 -Rule: Allow to www.example.com -Rule: Deny to 0.0.0.0/0 -----