Introduction

The FNCM operator previously handled all aspects of network policy creation automatically, applying default configurations with minimal user involvement. While this streamlined the deployment process, it left little flexibility for organizations that needed to enforce their own network controls or integrate with strict enterprise security policies.

With the release of FNCM 5.7.0, that balance is shifting.

This version introduces a more flexible, security-conscious approach to network policy management. Rather than enforcing policies directly, the operator now generates templates that customers can extract, review, and apply — enabling tighter control without sacrificing supportability.

Under the hood, this change reflects two key improvements:

• Operator RBAC tightened: The permissions that once allowed operators to create network policies cluster-wide have been removed, reducing unnecessary privileges and aligning better with enterprise security standards.

• Network Policy Decoupled: Network policy definitions are now generated as standalone template files. You decide which ones to apply, when, and how — based on your own namespace strategy and connectivity model.

In this blog, we’ll explore:

• What network policies do in FNCM deployments

• Installing Network Policy for Fresh Deployment in 5.7.0

• How Upgrade Script Handles Network Policy in 5.7.0

What Network Policies Do in FNCM Deployments

Network policies in Kubernetes control which pods can communicate with each other, and with external services. In FNCM deployments, these policies play a key role in protecting sensitive services such as CPE, Navigator, and GraphQL from unwanted access or unintended network exposure.

At a high level, FNCM network policies fall into two categories:

1. Ingress Policies

Ingress policies govern who is allowed to talk to FNCM components. In a typical deployment, this might include:

• Controlling traffic from ingress controllers like nginx or OpenShift router to reach component endpoints.

• Allowing monitoring tools (e.g., Prometheus) to scrape metrics or collect logs.

• Permitting internal service-to-service calls (like CPE calling CSS) within the FNCM namespace.

These policies help ensure that only authorized services can initiate connections to FNCM pods.

2. Egress Policies

Egress policies control where FNCM components are allowed to send traffic. Common destinations include:

• External LDAP and IDP servers for authentication

• Databases or file stores

• Connections to external servers like CMOD and CM8.

Without appropriate egress policies, components might be blocked from reaching critical dependencies—or worse, accidentally allowed to communicate externally without restriction.

Installing Network Policy for Fresh Deployment in 5.7.0

With the introduction of customizable network policies in FNCM 5.7.0, you now have the flexibility to manage policies based on your environment. But given the number of components involved — CPE, Navigator, GraphQL, CSS, and more — authoring each policy manually would be time-consuming and error-prone.

That’s where the deployment script comes in.

Rather than crafting each network policy YAML from scratch, you can use the deployment flow to generate operator-provided templates, review them, and apply only what you need

We’ll break this into two parts:

1. Enable the Operator to Generate Network Policy Templates

2. Retrieve the Templates After Deployment

Before we dive in, make sure you’re set up with the following prerequisites:

• Operating System: Windows, Linux, or macOS
• Deployment Scripts: Downloaded from the GitHub repository
• Python: Version 3.9 or later
• Java: Semeru 21 
• kubectl: Installed and configured with access to your cluster

1. Enable the Operator to Generate Network Policy Templates

Once your environment is set up, the first step is to configure the operator to generate network policy templates. This gives you the ability to review, modify, and selectively apply policies

You can do this in two ways:

Scenario 1: During Deployment

During the deployment process, you'll be prompted with:Do you want to generate Network Policies templates for your deployment?

If you respond with Yes, the operator will generate network policy templates for all applicable FNCM components

Scenario 2: Post-Deployment

If you didn’t enable template generation during deployment, you can still turn it on manually:

1. Run the following command:

   kubectl edit FNCMCluster -n <namespace>

2. Set the following field to true:
   

   spec:
      shared_configuration: 
         sc_generate_sample_network_policies: true

3. Save and exit the editor.

4. Wait for one full operator reconcile loop to complete. The templates will then be available for retrieval.
   

2. Retrieve the Templates After Deployment

Once the operator has generated the network policy templates, the next step is to extract them from the operator pod so you can review and customize them as needed.

You can do this in two ways:

Scenario 1: With mustgather Script in network policy mode

1. Run Mustgather.py in network policy mode
   

   python mustgather.py networkpolicy

2. When prompted, select the namespace
   
   
3. You'll see the network policies has been downloaded
   
   
4. Now if you want to apply the downloaded templates as it is you can give yes to the next question
   
   
5. If you had given no to the previous question and made changes to network policies, you can use the following command to apply them
   

   python mustgather.py networkpolicy --apply

Scenario 2: Retrieving templates manually

1. Log in to the target cluster as the <cluster-admin> user and access the target namespace.
2. Obtain the name of the FNCM stand-alone operator.

   export OPERATOR=$(kubectl get pods -l 'name=ibm-fncm-operator' | awk 'NR>1 {print $1}')

3. Copy the network policy templates from the operator pod to the desired location in your client machine.

   kubectl cp $OPERATOR:/tmp/<your_namespace>/network-policies .<your_namespace>/network-policies

4. Review the network policy templates that you copied from the operator pod.
5. After your review is complete, apply the network policies to your deployment.
   

   kubectl create -f <your_namespace>/network-policies/Content/egress -n <your_namespace>
   kubectl create -f <your_namespace>/network-policies/Content/ingress -n <your_namespace>
   

How Upgrade Script Handles Network Policy in 5.7.0

Upgrading to FNCM 5.7.0 introduces a new model for how network policies are treated during upgrades. These changes ensure that your customized policies are preserved, and that you have full control over post-upgrade policy management.

Here are the key changes:

Change 1: Operator Ownership Removed

During the upgrade, the script will remove the ownerReference from all existing network policies that were previously owned by the FNCM operator.

• The operator will no longer manage or update these policies.
• The customers are now fully responsible for maintaining them moving forward.
• However, the policies themselves are not deleted; only their ownership is decoupled from the operator.

Change 2: Template generation After Upgrade

• If your cluster is configured with sc_restricted_internet_access: true  the upgrade script will automatically add the following to the custom resource file
  

  spec:
     shared_configuration: 
        sc_generate_sample_network_policies: true

• Once upgrade is done you can run the python3 mustgather.py networkpolicy  to collect the templates for FNCMS 5.7.0 and compare them with existing once and modify them accordingly

Change 3: Previous Policies Backed Up

To help you with the comparison, the upgrade script automatically saves a snapshot of the original (operator-owned) policies into FNCMUpgrade/NetworkPolicies 

Credits

Author: Haresh Gautham S

Reviewers: Jason Kahn, Anisha Suresh