Network security

You can use network policies to control which connections are allowed or rejected.

Remember: You can optionally deploy multiple instances of IBM® Software Hub on your cluster. If you have more than one instance of IBM Software Hub on your cluster, you will need to adjust your network policies to ensure that each instance works as expected. For background information about multitenancy, see Multitenancy support.

Network policies

If the network isolation mode for the OpenShift® cluster is set to NetworkPolicy (the default), you can control the flow of traffic between different projects (namespaces). To define the flow, use the NetworkPolicy custom resource.

To learn more about network policies, see About network policy in the Red Hat® OpenShift Container Platform documentation:

By default, all pods in a project are accessible from other pods and network endpoints. To isolate one or more pods in a project, you can create NetworkPolicy objects in that project to indicate the allowed incoming connections.

Network policies are cumulative, so you can combine multiple network policies to satisfy complex network requirements.

Network policies for the Certificate manager

Run the following command to see the network policies that are applied to the project where the IBM Cloud Pak foundational services Certificate manager is installed:

oc get networkpolicy \
--namespace=${PROJECT_CERT_MANAGER}

Look for the following network policies:

deny-by-default
allow-from-same-namespace
allow-same-namespace

If any of the preceding network policies are applied to the project, create the following network policies for the Certificate manager:

Allow access from Operator Lifecycle Manager

The following network policy is applied to all of the pods in the Certificate manager project. The network policy allows the pods in the Certificate manager project to accept incoming communication from pods in the Operator Lifecycle Manager project.

cat <<EOF |oc apply -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-from-openshift-operator-lifecycle-manager
  namespace: ${PROJECT_CERT_MANAGER}
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: openshift-operator-lifecycle-manager
  policyTypes:
    - Ingress
EOF

Allow access from the API server

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  labels:
    component: cpfs3
  name: allow-webhook-access-from-apiserver
  namespace: ${PROJECT_CERT_MANAGER}
spec:
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          apiserver: "true"
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Allow access from the Certificate manager webhook

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-to-cert-manager-webhook
  namespace: ${PROJECT_CERT_MANAGER}
  labels:
    component: cpfs3
spec:
  podSelector:
    matchLabels:
      app: ibm-cert-manager-webhook
  ingress:
  - {}
EOF

Network policies for the License Service

Run the following command to see the network policies that are applied to the project where the IBM Cloud Pak foundational services License Service is installed:

oc get networkpolicy \
--namespace=${PROJECT_LICENSE_SERVICE}

Look for the following network policies:

deny-by-default
allow-from-same-namespace
allow-same-namespace

If any of the preceding network policies are applied to the project, create the following network policies for the License Service:

Allow access from Operator Lifecycle Manager

The following network policy is applied to all of the pods in the License Service project. The network policy allows the pods in the License Service project to accept incoming communication from pods in the Operator Lifecycle Manager project.

cat <<EOF |oc apply -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-from-openshift-operator-lifecyele-manager
  namespace: ${PROJECT_LICENSE_SERVICE}
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: openshift-operator-lifecycle-manager
  policyTypes:
    - Ingress
EOF

Allow access to usage reports

The following network policy is applied to the ibm-license-service-reporter-instance pods in the License Service project. The network policy allows the pods to respond to requests to download usage reports.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-to-ibm-licensing-service-reporter
  namespace: ${PROJECT_LICENSE_SERVICE}
  labels:
    component: cpfs3
spec:
  podSelector:
    matchLabels:
      app: ibm-license-service-reporter-instance
  ingress:
    - {}
  policyTypes:
    - Ingress
EOF

Allow usage metric submissions

The following network policy is applied to the ibm-licensing-service-instance pods in the License Service project. The network policy allows the pods to accept usage metrics.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-to-ibm-licensing-service-instance
  namespace: ${PROJECT_LICENSE_SERVICE}
  labels:
    component: cpfs3
spec:
  podSelector:
    matchLabels:
      app: ibm-licensing-service-instance
  ingress:
    - {}
  policyTypes:
    - Ingress
EOF

Network policies for the scheduling service

A cluster administrator or scheduling service administrator can create the following network policies to isolate the scheduling service:

Allow access to and from cluster resources
Allow access from the scheduling service webhook
Allow access to the Instana host agent

Allow access to and from cluster resources

The following network policy is applied to all of the pods in the scheduling service project.

Outgoing communication

The network policy denies all outgoing traffic project from the scheduling service project except:

Requests to the Red Hat OpenShift Container Platform API server
Query the Red Hat OpenShift Container Platform DNS service

Incoming communication

The network policy denies all incoming traffic to the scheduling service project except:

Incoming communication from the Red Hat OpenShift Container Platform API server
Incoming communication from Prometheus
Incoming communication from pods in the Operator Lifecycle Manager project

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: common
  namespace: ${PROJECT_SCHEDULING_SERVICE}
  labels:
    icpdsupport/addOnId: scheduling
    icpdsupport/ignore-on-nd-backup: "true"
    velero.io/exclude-from-backup: "true"
spec:
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          apiserver: "true"
  - to:
    - podSelector: {}
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-dns
  ingress:
  - from:
    - podSelector: {}
      namespaceSelector:
        matchLabels:
          openshift.io/cluster-monitoring: "true"
  - from:
    - podSelector: {}
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-operator-lifecycle-manager
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          apiserver: "true"
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
EOF

Allow access from the scheduling service webhook

The following network policy is applied to all of the pods in the scheduling service project. The network policy allows the pods in the scheduling service project to accept incoming communication from the scheduling service webhook.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webhook
  namespace: ${PROJECT_SCHEDULING_SERVICE}
  labels:
    icpdsupport/addOnId: scheduling
    icpdsupport/ignore-on-nd-backup: "true"
    velero.io/exclude-from-backup: "true"
spec:
  podSelector:
    matchLabels:
      netpol: webhook
  ingress:
  - {}
  policyTypes:
  - Ingress
EOF

Allow access to the Instana® host agent

The following network policy is applied to all of the pods in the scheduling service project. The network policy allows the pods in the scheduling service project to send metrics to the Instana host agent on the cluster.

Before you apply the network policy, set the INSTANA_NAMESPACE environment variable to the project where Instana host agent is installed:

export INSTANA_NAMESPACE=<project-name>

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: instana
  namespace: ${PROJECT_SCHEDULING_SERVICE}
spec:
  egress:
  - to:
    - podSelector: {}
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ${INSTANA_NAMESPACE}
    ports:
    - protocol: TCP
      port: 42699
  podSelector: {}
  policyTypes:
  - Egress
EOF

Network policies to isolate an instance of IBM Software Hub

A cluster administrator can create the following network policies to isolate an instance of IBM Software Hub:

Deny all network traffic in the operands project
Enable inter-pod communication in the operands project
Enable connections from the Red Hat OpenShift Container Platform Ingress Controller
Enable connections from the Red Hat OpenShift Container Platform monitoring stack
Enable the web client to communicate with the operands project
Enable the operands project to communicate with the operators project

These policies are combined to provide controlled access to the instance. You can repeat this process for each instance of IBM Software Hub on the cluster.

Deny all network traffic in the operands project

The following network policy is applied to all of the pods in the operands project. The network policy rejects all incoming traffic to the operands project.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-by-default
  namespace: ${PROJECT_CPD_INST_OPERANDS}
spec:
  podSelector:
    ingress: []
EOF

Enable inter-pod communication in the operands project

The following network policy is applied to all of the pods in the operands project. The network policy allows the pods in the operands project to communicate with each other.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
  namespace: ${PROJECT_CPD_INST_OPERANDS}
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
      - podSelector: {}
EOF

Enable connections from the Red Hat OpenShift Container Platform Ingress Controller

The following network policy is applied to all of the pods in the operands project. The network policy allows the pods in the operands project to accept incoming communication from the Red Hat OpenShift Container Platform Ingress Controller.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
  namespace: ${PROJECT_CPD_INST_OPERANDS}
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
EOF

Enable connections from the Red Hat OpenShift Container Platform monitoring stack

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
  namespace: ${PROJECT_CPD_INST_OPERANDS}
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: monitoring
EOF

Enable the web client to communicate with the operands project

The following network policy is applied to the ibm-nginx pods in the operands project. The network policy allows the ibm-nginx pods in the operands project to accept incoming communication from the IBM Software Hub web client.

cat <<EOF |oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-access-to-front-door
  namespace: ${PROJECT_CPD_INST_OPERANDS}
spec:
  podSelector:
    matchLabels:
      component: "ibm-nginx"
  policyTypes:
    - Ingress
  ingress:
    - {}
EOF

Enable the operands project to communicate with the operators project

cat <<EOF |oc apply -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-from-cpd-operator-ns
  namespace: ${PROJECT_CPD_INST_OPERANDS}
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ${PROJECT_CPD_INST_OPERATORS}
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Restricting egress

You should consider whether you need to take additional steps to restrict egress from IBM Software Hub. In some environments, such as clusters running in a restricted network, this might be unnecessary; your existing network configuration or firewall rules should be sufficient to restrict egress.

It is strongly recommended that you review the Red Hat OpenShift security guide to determine which security measures you should implement in your environment.

Network policies implemented by individual services

The following services implement additional network policies as part of their installation.

Service	Automatically installed network policies
AI Factsheets	The service does not automatically create network policies.
Anaconda Repository for IBM Cloud Pak for Data	Not applicable. The service is not installed on the cluster.
Analytics Engine powered by Apache Spark	The service does not automatically create network policies.
Cognos Analytics	The service does not automatically create network policies. If you plan to provision an instance of Cognos Analytics in a tethered project and you applied network policies for the Certificate manager, License Service, and IBM Software Hub control plane, you must create a network policy to enable the service instance to communicate with these components. For more information on creating the network policy, see Adding a network policy for Cognos Analytics.
Cognos Dashboards	The service does not automatically create network policies.
Data Gate	Data Gate automatically creates the following defensive network policies: `dg-<instance_id>-data-gate-network-policy` Allows incoming traffic from within Data Gate pods as well from Db2 for z/OS. All other incoming traffic is denied. `dg-<instance_id>-deny-all-network-policy` Denies all incoming traffic to Data Gate pods. `dg-<instance_id>-ui-network-policy` Allows incoming traffic to a specific port of the Data Gate UI pod. All other incoming traffic to the UI pod is denied.
Data Privacy	Data Privacy automatically creates the following defensive network policies: `dp-api-policy` Allows incoming traffic to specific ports of the `dp-api-` pod from the `dp-privacyprocessor-` pod. All other incoming traffic to the `dp-api-` pods is denied. `dp-privacyprocessor-policy` Allows incoming traffic to specific ports of the `dp-privacyprocessor-` pod from the `wkc-gov-ui-` pod. All other incoming traffic to the `dp-privacyprocessor-` pods is denied. `dp-subset-policy` Allows incoming traffic to specific ports of the `dp-subset-` pod from the `dp-api-` pod and `dp-privacyprocessor-` pod. All other incoming traffic to the `dp-subset-` pods is denied. `dp-ui-policy` Allows incoming traffic to specific ports of the `dp-ui-` pod. All other incoming traffic to the `dp-ui` pods is denied.
Data Product Hub
Data Refinery	The service does not automatically create network policies.
Data Replication	Data Replication automatically creates the following defensive network policies: `replication-ibm-replication-apiserver-network-policy` Allows incoming traffic to the `apiserver` pods from the `nginx` pods and the Data Replication operator pod. All other incoming traffic to the `apiserver` pods is denied. `replication-ibm-replication-engine-network-policy` Allows incoming traffic to the `replication-engine` pods from the `apiserver` pods and the Data Replication operator pod. All other incoming traffic to the `replication-engine` pods is denied.
DataStage	DataStage automatically creates the following defensive network policies: `datastage-ibm-datastage-network-policy` Allows incoming traffic to specific ports of the DataStage pods from `ibm-nginx` pods and DataStage pods. Denies all other incoming traffic. `datastage-ibm-datastage-px-compute-network-policy` Allows incoming traffic to any port on the `px-compute` pods from DataStage pods. `datastage-ibm-datastage-px-runtime-network-policy` Allows incoming traffic to any port on the `px-runtime` pods from `ibm-nginx` pods and `px-compute` pods.
Data Virtualization	Data Virtualization automatically creates the following defensive network policies: `dv-deny-by-default` Denies all incoming traffic to Data Virtualization pods. `dv-addon` Allows incoming traffic from the `ibm-nginx` pods to ports 8080 and 8443 of the Data Virtualization `addon` pods. Denies all other incoming traffic. `dv-service-provider` Allows incoming traffic from any pods in the operands project to port 3443 of the Data Virtualization `service-provider`. Denies all other incoming traffic.
Db2	Db2 automatically creates the following defensive network policy: `database-core-np-ext` Allows incoming traffic to specific ports of the `zen-database-core` pods from any pod. In addition, when you create a database instance, Db2 automatically creates the following defensive network policies: `c-db2oltp-<instance_id>` Allows incoming traffic to any port of the database instance pods from the other pods associated with the instance. `c-db2oltp-<instance_id>-ext` Allows incoming traffic to specific ports of the database engine pods from any pod.
Db2 Big SQL	Db2 Big SQL automatically creates the following defensive network policies: `bigsql-deny-by-default` Denies all incoming traffic to Db2 Big SQL pods. `bigsql-addon` Allows incoming traffic to specific ports of the Db2 Big SQL `addon` pods from the `ibm-nginx` pods. Denies all other incoming traffic. `bigsql-service-provider` Allows incoming traffic to specific ports of the Db2 Big SQL `service-provider` pods from any pods in the operands project. Denies all other incoming traffic.
Db2 Data Management Console	Db2 Data Management Console automatically creates the following defensive network policies: `ibm-dmc-addon-api` `ibm-dmc-addon-ui` `ibm-dmc-<instance-id>-admin` `ibm-dmc-<instance-id>-dbapi` `ibm-dmc-<instance-id>-default-net` `ibm-dmc-<instance-id>-explain` `ibm-dmc-<instance-id>-job-scheduler` `ibm-dmc-<instance-id>-monitor` `ibm-dmc-<instance-id>-nginx` `ibm-dmc-<instance-id>-registry-manager` `ibm-dmc-<instance-id>-runsql`
Db2 Warehouse	Db2 Warehouse automatically creates the following defensive network policy: `database-core-np-ext` Allows incoming traffic to specific ports of the `zen-database-core` pods from any pod. In addition, when you create a database instance, Db2 Warehouse automatically creates the following defensive network policies: `c-db2wh-<instance-id>` Allows incoming traffic to any port of the database instance pods from the other pods associated with the instance. `c-db2wh-<instance-id>-ext` Allows incoming traffic to specific ports of the database engine pods from any pod.
Decision Optimization	Decision Optimization automatically creates the following defensive network policy: `dods-ibm-dods-dd-network-policy` Allows incoming traffic to specific ports of `ibm-dods` pods from `ibm-nginx` pods and `monitoring-cronjob` pods. Denies all other incoming traffic.
EDB Postgres	The service does not automatically create network policies.
Execution Engine for Apache Hadoop	Execution Engine for Apache Hadoop automatically creates the following defensive network policies: `hadoop-kubectl-network-policy` Allows incoming traffic to the `hadoop-kubectl` pods from `ibm-nginx` pods. Denies all other incoming traffic. `utils-api-network-policy` Allows incoming traffic to the `utils-api` pods from `ibm-nginx` pods. Denies all other incoming traffic.
IBM Knowledge Catalog	When you install IBM Knowledge Catalog, Db2U automatically creates the following defensive network policies for the internal database: `c-db2oltp-wkc` Allows incoming traffic to any port of the internal database pods from the other pods associated with the internal database. `c-db2oltp-wkc-ext` Allows incoming traffic to specific ports of the internal database engine pods from any pod.
IBM Knowledge Catalog Premium	IBM Knowledge Catalog Premium automatically creates the following defensive network policies: `govgenai-network-policy` Allows incoming traffic to specific ports from pods in the instance project. Denies all other incoming traffic. In addition, when you install IBM Knowledge Catalog Premium, Db2U automatically creates the following defensive network policies for the internal database: `c-db2oltp-wkc` Allows incoming traffic to any port of the internal database pods from the other pods associated with the internal database. `c-db2oltp-wkc-ext` Allows incoming traffic to specific ports of the internal database engine pods from any pod.
IBM Knowledge Catalog Standard	IBM Knowledge Catalog Standard automatically creates the following defensive network policies: `govgenai-network-policy` Allows incoming traffic to specific ports from pods in the instance project. Denies all other incoming traffic. In addition, when you install IBM Knowledge Catalog Standard, Db2U automatically creates the following defensive network policies for the internal database: `c-db2oltp-wkc` Allows incoming traffic to any port of the internal database pods from the other pods associated with the internal database. `c-db2oltp-wkc-ext` Allows incoming traffic to specific ports of the internal database engine pods from any pod.
IBM Master Data Management	IBM Master Data Management automatically creates the following defensive network policies: `mdm-deny-all-<instance-id>` Denies all incoming traffic to the IBM Master Data Management deployment. `mdm-<instance-id>-ibm-rabbitmq` Allows incoming traffic to specific ports of RabbitMQ server from the RabbitMQ service pods associated with the IBM Master Data Management deployment. `mdm-allow-elasticsearch-<instance-id>` Allows incoming traffic to Elasticsearch pods from specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `mdm-allow-foundationdb-<instance-id>` Allows incoming traffic to FoundationDB pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. The IBM Master Data Management operator pods. `mdm-allow-mdm-config-ui-<instance-id>` Allows incoming traffic to `mdm-config-ui` pods from `ibm-nginx` pods in the instance project. `mdm-allow-mdm-configuration-<instance-id>` Allows incoming traffic to `mdm-configuration` pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `ibm-nginx` pods in the instance project. `mdm-allow-mdm-data-<instance-id>` Allows incoming traffic to `mdm-data` pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `ibm-nginx` pods in the instance project. `mdm-allow-mdm-em-ui-<instance-id>` Allows incoming traffic to `mdm-em-ui` pods from: The IBM Master Data Management Neo4j migration pod `ibm-nginx` pods in the instance project. `mdm-allow-mdm-job-<instance-id>` Allows incoming traffic to `mdm-job` pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. The Spark driver pods associated with the IBM Master Data Management deployment `ibm-nginx` pods in the instance project. `mdm-allow-mdm-matching-<instance-id>` Allows incoming traffic to `mdm-matching` pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `ibm-nginx` pods in the instance project. `mdm-allow-mdm-model-<instance-id>` Allows incoming traffic to `mdm-model` pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `ibm-nginx` pods in the instance project. `mdm-allow-neo4j-<instance-id>` Allows incoming traffic to Neo4j pods from: Specific IBM Master Data Management pods associated with the IBM Master Data Management service deployment IBM Master Data Management operator pods Neo4j-related pods within the Neo4j instance `mdm-allow-rabbitmq-<instance-id>` Allows incoming traffic to RabbitMQ pods from specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `mdm-allow-redis-<instance-id>` Allows incoming traffic to Redis pods from specific IBM Master Data Management pods associated with the IBM Master Data Management deployment. `mdm-allow-spark-driver-<instance-id>` Allows incoming traffic to Spark driver pods from the Spark executor pods associated with the IBM Master Data Management deployment. `mdm-allow-spark-executor-<instance-id>` Allows incoming traffic to Spark executor pods from: The Spark driver pods associated with the IBM Master Data Management deployment The other Spark executor pods associated with the IBM Master Data Management deployment
IBM StreamSets	IBM StreamSets automatically creates the following defensive network policies: `ibm-streamsets-ingress-network-policy` Allows incoming traffic to IBM StreamSets pods from `ibm-nginx` pods and IBM StreamSets pods within the same namespace. Denies all other incoming traffic.
Informix	When you create a database instance, Informix automatically creates the following defensive network policies: `informix-<instance-id>-cm` Allows incoming traffic to specific ports of the `informix-<instance-id>-cm-0` pod from the Informix database instance. Allows outgoing traffic from the `informix-<instance-id>-cm-0` pod to the Informix database instance. `informix-<instance-id>-cp4dapi` Allows incoming traffic to specific ports of the `informix-<instance-id>-cp4dapi-` pod from the Informix database instance. Allows outgoing traffic from the `informix-<instance-id>-cp4dapi-` pod to the `ibm-nginx` pods. `informix-<instance-id>-monitor` Allows incoming traffic to specific ports of the `informix-<instance-id>-monitor-` pod from the Informix database instance. Allows outgoing traffic from the `informix-<instance-id>-monitor-` pod to the `ibm-nginx` pods. `informix-<instance-id>-server` Allows incoming traffic to specific ports of the `informix-<instance-id>-server-0` pod from the Informix database instance. Allows outgoing traffic from the `informix-<instance-id>-server-0` pod to the following pods: `zen-audit` pod in the operators project Informix database instance `informix-<instance-id>-wlistener` Allows incoming traffic to specific ports of the `informix-<instance-id>-wlistener-` pod from the Informix database instance. Allows outgoing traffic from the `informix-<instance-id>-wlistener-` pod to the Informix database instance.
MANTA Automated Data Lineage	The service does not automatically create network policies.
OpenPages	When you create an OpenPages service instance, OpenPages automatically creates the following defensive network policy: `openpages-<instance-name>-network-policy` Allows incoming traffic to specific ports of the OpenPages service instance.
Orchestration Pipelines	The service does not automatically create network policies.
Planning Analytics	The service does not automatically create network policies.
Product Master	Product Master automatically creates the following defensive network policies: `np-admin` Allows incoming traffic to specific ports of the `productmaster-admin` pod from the `productmaster-restapi` pods. Denies all other incoming traffic. `np-ftsind` Allow incoming traffic to specific ports of `productmaster-fts-indexer` pod. Denies all other incoming traffic. `np-ftspim` Allow incoming traffic to specific ports of the `productmaster-ftspim` pod from the `productmaster-restapi` pods and `productmaster-sch` pods. Denies all other incoming traffic. `np-hazelcast` Allow incoming traffic to specific ports of the `productmaster-hazelcast` pod from the following pods: `productmaster-admin` `productmaster-fts-indexer` `productmaster-magento` `productmaster-ml` `productmaster-pim-collector` `productmaster-restapi` `productmaster-sch` `productmaster-wfl` Denies all other incoming traffic. `np-ml` Allow incoming traffic to specific ports of the `productmaster-ml` pod from the `product master-sch` and `productmaster-wfl` pods. Denies all other incoming traffic. `np-persona` Allow incoming traffic to specific ports of the `productmaster-persona` pod. Denies all other incoming traffic. `np-rest` Allow incoming traffic to specific ports of the `productmaster-rest api` pod from the following pods: `productmaster-admin` `productmaster-magento` `productmaster-wfl` Denies all other incoming traffic. `np-sch` Allow incoming traffic specific ports of the `productmaster-sch` pod from the `productmaster-admin` pods and `productmaster-restapi` pods. Denies all other incoming traffic. `np-wfl` Allow incoming traffic to specific ports of the `productmaster-sch` pod from the `productmaster-admin` pods and `productmaster-restapi` pods. Denies all other incoming traffic.
RStudio® Server Runtimes	The service does not automatically create network policies.
SPSS Modeler	The service does not automatically create network policies.
Synthetic Data Generator	The service does not automatically create network policies.
Voice Gateway	Voice Gateway automatically creates the following network policy: `voicegateway-cr` Allows incoming traffic from outside the cluster to the Voice Gateway pod.
Watson Discovery	Watson Discovery automatically creates the following defensive network policies: `wd-discovery-deny-ingress-netpol` Denies all incoming connections to Watson Discovery pods. `wd-discovery-deny-external-netpol` Denies all outgoing connections from Watson Discovery pods. `wd-discovery-allow-cluster-netpol` Allows outgoing traffic to other pods in the cluster from all Watson Discovery pods. `wd-discovery-crawler-external-netpol` Allows outgoing traffic to external services outside of the cluster from `wd-discovery-crawler` pods. `wd-discovery-kubeapi-external-netpol` Allows outgoing traffic to an external Kubernetes API server outside of the cluster from Watson Discovery pods with the label `require-kubeapi-access=true`. `wd-discovery-postgres-external-netpol` Allows outgoing traffic to an external Kubernetes API server outside of the cluster from `wd-discovery-cn-postgres` pods. `wd-discovery-webhook-external-netpol` Allows outgoing traffic to external services outside of the cluster from `wd-discovery-webhook-connector` pods. `wd-discovery-` The network policies that start with `wd-discovery-` allow all incoming connections to Watson Discovery component pods from: Watson Discovery pods IBM Software Hub control plane pods This includes the following network policies: `wd-discovery-cn-postgres` `wd-discovery-cnm-api` `wd-discovery-converter` `wd-discovery-crawler` `wd-discovery-elastic` `wd-discovery-enrichment-service` `wd-discovery-entity-suggestion` `wd-discovery-entity-training` `wd-discovery-etcd-netpol` `wd-discovery-gateway` `wd-discovery-glimpse-builder` `wd-discovery-glimpse-query` `wd-discovery-haywire` `wd-discovery-hdp-rm` `wd-discovery-hdp-worker` `wd-discovery-ingestion-api` `wd-discovery-inlet` `wd-discovery-management` `wd-discovery-minerapp` `wd-discovery-orchestrator` `wd-discovery-outlet` `wd-discovery-pgbouncer` `wd-discovery-rabbitmq` `wd-discovery-ranker-master` `wd-discovery-ranker-rest` `wd-discovery-rapi` `wd-discovery-sdu` `wd-discovery-serve-ranker` `wd-discovery-stateless-api-model-runtime` `wd-discovery-stateless-api-rest-proxy` `wd-discovery-tooling` `wd-discovery-training-crud` `wd-discovery-training-rest` `wd-discovery-webhook-connector` `wd-rabbitmq-discovery` Allow all incoming connections to Watson Discovery component pods from: Watson Discovery pods IBM Software Hub control plane pods
Watson Machine Learning	The service does not automatically create network policies.
Watson OpenScale	Watson OpenScale automatically creates the following defensive network policies: `aiopenscale-ingress-network-policy` Allows incoming traffic from platform, AI Factsheets, OpenPages, Watson Machine Learning, Watson OpenScale, and common core service pods in the same operand project. Also allows incoming traffic Watson OpenScale operator pods in the operator project. Denies all other incoming traffic.
Watson Speech services	Watson Speech services automatically creates the following defensive network policy: `<speech-cr-name>-network-policy` Allows incoming traffic to the Watson Speech services pods from pods in the operands project with any of the following labels: `app.kubernetes.io/name: monitoring-cronjob` `component: ibm-nginx` `component: watson-gateway` `release: speech-cr` Allows incoming traffic to the Watson Speech services pods from pods in the operators project with any of the following labels: `app.kubernetes.io/name: cloud-native-postgresql` `app.kubernetes.io/name: watson-speech`
Watson Studio	The service does not automatically create network policies.
Watson Studio Runtimes	The service does not automatically create network policies.
watsonx.ai™	The service does not automatically create network policies.
watsonx Assistant	watsonx Assistant automatically creates the following defensive network policies: `wa-data-governor-ibm-data-governor-deny-all-network-policy` `wa-data-governor-ibm-data-governor-network-policy` `wa-data-governor-ibm-elasticsearch-headless-srv` `wa-data-governor-kafka-entity-operator` `wa-data-governor-kafka-network-policy-kafka` `wa-data-governor-kafka-network-policy-zookeeper` `wa-etcd` `wa-network-policy-analytics` `wa-network-policy-clu-embedding` `wa-network-policy-clu-serving` `wa-network-policy-clu-training` `wa-network-policy-clu-triton-serving` `wa-network-policy-deny-all` `wa-network-policy-dialog` `wa-network-policy-dragonfly-clu-mm` `wa-network-policy-ed` `wa-network-policy-etcd` `wa-network-policy-gateway` `wa-network-policy-incoming-webhooks` `wa-network-policy-integrations` `wa-network-policy-nlu` `wa-network-policy-postgres` `wa-network-policy-recommends` `wa-network-policy-redis` `wa-network-policy-spellchecker-mm` `wa-network-policy-store` `wa-network-policy-store-admin` `wa-network-policy-system-entities` `wa-network-policy-tfmm` `wa-network-policy-ui` `wa-network-policy-wa-knative-wa-clu-dlq`
watsonx Code Assistant™	The service does not automatically create network policies.
Watsonx Code Assistant™ for Red Hat Ansible® Lightspeed	The service does not automatically create network policies.
watsonx.data™	watsonx.data automatically creates the following defensive network policies: `ibm-lh-deny-network-policy` `ibm-lh-lakehouse-cas-network-policy` `ibm-lh-lakehouse-hive-metastore-network-policy` `ibm-lh-lakehouse-ibm-lh-postgres-network-policy` `ibm-lh-lakehouse-minio-network-policy` `ibm-lh-lakehouse-presto-01-coordinator-network-policy` `ibm-lh-lakehouse-presto-01-worker-network-policy` `ibm-lh-lakehouse-qhmm-network-policy`
watsonx.data integration	The StreamSets component in watsonx.data integration automatically creates the following defensive network policies: `ibm-streamsets-sdi-ingress-network-policy` Allows incoming traffic to StreamSets pods from `ibm-nginx` pods and StreamSets pods within the same namespace. Denies all other incoming traffic.
watsonx.governance™	If you install OpenPages, the service automatically creates the following network policy: `openpages-<instance-name>-network-policy` For more information, see the OpenPages entry. If you install Watson OpenScale, the service automatically creates the following network policy: `aios-ingress-network-policy` For more information, see the Watson OpenScale entry.
watsonx™ Orchestrate	watsonx Orchestrate automatically creates the following defensive network policies: `wo-watson-orchestrate-network-policy-default-deny` Denies all incoming connections to and outgoing connections from watsonx Orchestrate pods in the operands project. `wo-watson-orchestrate-network-policy-allow-external` Allows outgoing traffic to external services outside of the cluster from watsonx Orchestrate pods with the label `wo.watsonx.ibm.com/external-access: 'true'`. `wo-watson-orchestrate-network-policy-cluster-egress` Allows outgoing traffic to other pods in the cluster from watsonx Orchestrate pods. `wo-watson-orchestrate-network-policy-cp-egress` Allows outgoing traffic to the Kubernetes API server from watsonx Orchestrate with the label `wo.watsonx.ibm.com/control-plan-access=true: 'true'`. `wo-watson-orchestrate-network-policy-common-ingress` Allows incoming traffic to watsonx Orchestrate pods from the following pods: `cloud-native-postgresql` `entity-operator` `ibm-events-operator` `ibm-nginx` `ibm-rabbitmq-operator` `ibm-redis-cp-operator` `ibm-watsonx-orchestrate-apicatalog` `mongodb-enterprise-operator` `usermgmt` `zen-core` `zen-core-api` Denies all other incoming traffic.