<commit_before>// Module included in the following assemblies:
//
// * logging/cluster-logging-deploying.adoc

[id="cluster-logging-deploy-multitenant_{context}"]
= Allowing traffic between projects when network isolation is enabled

Your cluster network provider might enforce network isolation. If so, you must allow network traffic between the projects that contain the operators deployed by OpenShift Logging.

Network isolation blocks network traffic between pods or services that are in different projects. OpenShift Logging installs the _OpenShift Elasticsearch Operator_ in the `openshift-operators-redhat` project and the _Red Hat OpenShift Logging Operator_ in the `openshift-logging` project. Therefore, you must allow traffic between these two projects.

{product-title} offers two supported choices for the default Container Network Interface (CNI) network provider, OpenShift SDN and OVN-Kubernetes. These two providers implement various network isolation policies.

OpenShift SDN has three modes:

network policy:: This is the default mode. If no policy is defined, it allows all traffic. However, if a user defines a policy, they typically start by denying all traffic and then adding exceptions. This process might break applications that are running in different projects. Therefore, explicitly configure the policy to allow traffic to egress from one logging-related project to the other.

multitenant:: This mode enforces network isolation. You must join the two logging-related projects to allow traffic between them.

subnet:: This mode allows all traffic. It does not enforce network isolation. No action is needed.

OVN-Kubernetes always uses a *network policy*. Therefore, as with OpenShift SDN, you must configure the policy to allow traffic to egress from one logging-related project to the other.

.Procedure

* If you are using OpenShift SDN in *multitenant* mode, join the two projects. For example:
+
[source,terminal]
----
$ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
----

* Otherwise, for OpenShift SDN in *network policy* mode and OVN-Kubernetes, perform the following actions:

.. Set a label on the `openshift-operators-redhat` namespace. For example:
+
[source,terminal]
----
$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
----

.. Create a network policy object in the `openshift-logging` namespace that allows ingress from the `openshift-operators-redhat` project to the `openshift-logging` project. For example:
+
[source,yaml]
----
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-openshift-operators-redhat
spec:
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: openshift-operators-redhat
----<commit_msg>RHDEVDOCS-3202 Tracker for issue#35108 logging/cluster-logging-deploying.adoc<commit_after>// Module included in the following assemblies:
//
// * logging/cluster-logging-deploying.adoc

[id="cluster-logging-deploy-multitenant_{context}"]
= Allowing traffic between projects when network isolation is enabled

Your cluster network provider might enforce network isolation. If so, you must allow network traffic between the projects that contain the operators deployed by OpenShift Logging.

Network isolation blocks network traffic between pods or services that are in different projects. OpenShift Logging installs the _OpenShift Elasticsearch Operator_ in the `openshift-operators-redhat` project and the _Red Hat OpenShift Logging Operator_ in the `openshift-logging` project. Therefore, you must allow traffic between these two projects.

{product-title} offers two supported choices for the default Container Network Interface (CNI) network provider, OpenShift SDN and OVN-Kubernetes. These two providers implement various network isolation policies.

OpenShift SDN has three modes:

network policy:: This is the default mode. If no policy is defined, it allows all traffic. However, if a user defines a policy, they typically start by denying all traffic and then adding exceptions. This process might break applications that are running in different projects. Therefore, explicitly configure the policy to allow traffic to egress from one logging-related project to the other.

multitenant:: This mode enforces network isolation. You must join the two logging-related projects to allow traffic between them.

subnet:: This mode allows all traffic. It does not enforce network isolation. No action is needed.

OVN-Kubernetes always uses a *network policy*. Therefore, as with OpenShift SDN, you must configure the policy to allow traffic to egress from one logging-related project to the other.

.Procedure

* If you are using OpenShift SDN in *multitenant* mode, join the two projects. For example:
+
[source,terminal]
----
$ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
----

* Otherwise, for OpenShift SDN in *network policy* mode and OVN-Kubernetes, perform the following actions:

.. Set a label on the `openshift-operators-redhat` namespace. For example:
+
[source,terminal]
----
$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
----

.. Create a network policy object in the `openshift-logging` namespace that allows ingress from the `openshift-operators-redhat` project to the `openshift-logging` project. For example:
+
[source,yaml]
----
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-openshift-operators-redhat
  namespace: openshift-logging
spec:
  ingress:
    - from:
      - podSelector: {}
    - from:
      - namespaceSelector:
          matchLabels:
            project: openshift-operators-redhat
----
{'fraction_non_alphanumeric': 0.06777292576419214, 'fraction_numerical': 0.0022707423580786024, 'mean_word_length': 4.505769230769231, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1208111', 'n_tokens_mistral': 1473, 'n_tokens_neox': 1410, 'n_words': 674}