Configuring cluster network policy

Network policies to manage access to services in the cluster (ingress)

• Example 1: The following example sets a network policy to allow ingress traffic from OpenShift Ingress Controller (Router):

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress

• Example 2: The following example sets a network policy to allow ingress traffic from OpenShift Monitoring:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-monitoring
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: monitoring
    podSelector: {}
    policyTypes:
    - Ingress
  

• Example 3: The following example sets a network policy to allow traffic between pods in the same FNCM namespace:

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}

  Note: The pod selectors (podSelector) in these examples are for all pods deployed in the same namespace which includes non-FNCM pods. Therefore, all the pods deny traffic that is not explicitly allowed by the network policies of the namespace.

Deny all network policies

If a deny-all network policy is defined in the cluster as shown in the following NetworkPolicy, then delete it from the cluster.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Network policies to manage access to external services (egress)

• When the shared_configuration.sc_generate_sample_network_policies parameter in the custom resource is set to "true”, the operator generates the following templates but does not applies them to the deployment:

  • A deny-all egress network policy ({{ meta.name }}-fncm-egress-deny-all).
  • An allow-all egress network policy ({{ meta.name }}-fncm-egress-allow-all).
  • An allow-same-namepace egress network policy in the FNCM deployment namespace ({{ meta.name }}-fncm-egress-allow-same-namespace).
  • An egress communications policy for the Kubernetes API and DNS services ({{ meta.name }}-fncm-egress-allow-k8s-services).
  • A directory service server or LDAP egress network policy ({{ meta.name }}-fncm-egress-allow-ldap).
  • Egress network policies for some databases associated with the deployment.

  Where {{ meta.name }} is "fncmdeploy" for FileNet Content Manager deployments.

  Attention:

  When your OpenShift cluster uses OpenShift software-defined networking (SDN) as the network plug-in type, the allow-same-namespace and allow-k8s-services egress network policies for the FNCM deployment use an empty pod selector (podSelector: {}). If non-FNCM pods run in the same namespace as FNCM, then they might be affected by the empty pod selectors. If needed, create your own egress network policy to allow outgoing traffic from the non-FNCM pods.

  For CNCF environments, you need to update the following parameter values:

  • Set the value of sc_api_namespace as "default".
  • Set the value of sc_dns_namespace as "kube-system".

  If you are using AWS Elastic Kubernetes Services(EKS) and Calico network topology, the pods might take longer to start, and restart multiple times before they become ready.
• Note: When the shared_configuration.sc_drivers_url parameter has a valid value, a {{ meta.name }}-fncm-operator-default-egress network policy is also created to provide access to the server that is defined in the parameter value.

  • Option 1: Create a custom "catch-all" egress network policy

    The following example shows a "catch all" network policy that uses the podSelector.matchLabels parameter set to com.ibm.fncm.networking/egress-external-app: "true". The policy allows all the FNCM components to communicate to the addresses defined in the ipBlock.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: "{{ meta.name }}-fncm-egress-external-app"
      namespace: "{{ meta.namespace }}"
      labels:
        app.kubernetes.io/name: "{{ meta.name }}-fncm-egress-external-app"
    spec:
      podSelector:
        matchLabels:
          com.ibm.fncm.networking/egress-external-app: "true"
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: # IP address your external application .  For example: 1.2.3.4/32
        ports:
        - protocol: #Protocol UDP or TCP
          port: #Port number
      - to:
        - ipBlock:
            cidr: # IP address your external application .  For example: 1.2.3.4/32
        ports:
        - protocol: #Protocol UDP or TCP
          port: #Port number

    Where {{ meta.name }} is "fncmdeploy" for FileNet Content Manager deployments. The {{ meta.namespace }} value is the namespace of your FNCM deployment (for example fncm-project).

    Tip: Tools such as dig or nslookup can be used to do a DNS lookup on a host to retrieve the IP address.

  • Option 2: Create a custom "component-level" egress network policy

    The following example shows a "component-level" network policy that uses the podSelector.matchLabels parameter set to com.ibm.fncm.networking/egress-external-app-component: "BAN". The network policy allows the FNCM component to communicate to the addresses defined in the ipBlock.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: "{{ meta.name }}-fncm-egress-external-app-component"
      namespace: "{{ meta.namespace }}"
      labels:
        app.kubernetes.io/name: "{{ meta.name }}-fncm-egress-external-app-component"
    
    spec:
      podSelector:
        # matchExpressions:
        #   - key: com.ibm.fncm.networking/egress-external-app-component
        #     operator: In
        #     values:
        #       - BAN
        #       - FNCM
        matchLabels:
          com.ibm.fncm.networking/egress-external-app-component: "BAN"
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: 1.2.3.4/32
        ports:
        - protocol: TCP
          port: 443

    The following table lists the capabilities that have a need to access external services.

    Table 1. Component labels for the pod selector

    Capability	matchLabels	Description
    Navigator	com.ibm.fncm.networking/egress-external-app-component: "BAN"	The following plug-ins, which are located in /opt/ibm/intPlugins, connect to external services. ./eDS/edsPlugin.jar ./BAI/BAIPlugin.jar ./iccsap/iccsapPlugin.jar ./SSO/application-discovery.jar ./SSO/platformPlugin.jar ./sharePoint/ sharePointOnlinePlugin.jar ./DocuSign/DocuSignPlugin.jar Deployments using an external data service for edsPlugin must allow its endpoint. The application-discovery and platformPlugin must be able to connect to the App Engine pods. Other plug-ins that might need to connect outside of the cluster, includes: Send mail smtp services. Microsoft office for the web. Sharepoint online services. DocuSign. CM8. CMOD. Box.
    Content Cortex	com.ibm.fncm.networking/egress-external-app-component: "FNCM"	If you extend your deployment to include external services that are not deployed within the same Content Cortex namespace as your deployment, create additional egress network policies by using the component name "FNCM". The following examples are external services that are not deployed within the same namespace as the Content Cortex deployment: Custom code that calls out to external services incorporated into CPE as code modules or associated with component queues or added to the classpath. Also custom code that is integrated as BAN plug-ins that use external services. Full text indexing engines such as OpenSearch or Elasticsearch. Storage devices or storage technologies accessible to the CPE component using APIs that do not utilize the Kubernetes storage provisioners and persistent volumes. eMail services integrated with the CPE component and BAN. IBM products associated with the Content Cortex, such as Content Collector and Enterprise Records that have tools or services residing outside of the Kubernetes cluster where the Kubernetes deployed services use call-back or act as a client. External data services invoked from Process Engine (WSInvoke) or BAN (Navigator External Data Services). Database services not listed in the CR that are directly invoked from custom code or by using the FileNet Process Engine DBExecute function. IBM products with deployments on WebSphere traditional that utilize the services from FNCM or BAN from a containerized deployment such as IBM Content on Demand, or IBM Business Automation Workflow. Components in the Kubernetes-based FNCM or BAN deployments must be able to call out to the services hosted in WebSphere traditional. Webhooks as a part of a CS-Graphql application. External Key management services. Multiple deployments of FNCM in distinct OCP clusters to support geographically dispersed Content Cortex domain. Legacy deployments of the Content Cortex based on application servers that exist side-by-side against the same Content Cortex domain.