Prepare your CLI tools and network

Now that we’ve covered the various ways you can implement Palo Alto VM-Series firewalls within OpenShift, we'll show how to prepare your command-line tools for a deployment. 

Prerequisites:

• OpenShift Virtualization installed.
  • virtctl command (provided via the OpenShift Web UI).
• NMState Operator installed.
• SR-IOV Operator installed (optional, only if SR-IOV is required).

In this lesson, you will:

• Download and prepare your command-line utilities.
• Prepare your network in advance of the firewall deployment. 

Preparation: Download command-line utilities

First, we will download the oc command-line utility:

1. Go to the main page of your OpenShift Web UI Management Console.
2. At the top right corner of the Web UI, look for a question mark (?) and select Command Line Tools.
3. Near the bottom of the page, look for a section entitled oc - OpenShift Command Line interface (CLI) and click the download link which best describes your system architecture (i.e., “Download oc for Linux for x86_64”)

4. Unpack this executable and ensure you can run it on the command line similar to this example:

   $ oc version
   Client Version: 4.18.4
   Server Version: 4.18.4
   Kubernetes Version: v5.3.1

Next, we’ll download the virtctl command-line utility.

1. Go to the main page of your OpenShift Web UI Management Console.
2. At the top right-hand corner of the Web UI, look for a question mark (?) and select Command Line Tools.
3. Near the bottom of the page, look for a section entitled virtctl - KubeVirt Command Line Interface and click the download link which best describes your system architecture (i.e., “Download virtctl for Linux for x86_64”)

4. Unpack this executable and ensure you can run it on the command line similar to this example:

   $ virtctl version
   Client Version: version.Info{GitVersion:"1.5.0"}
   Server Version: version.Info{GitVersion:"v1.5.2-19-gf58b2efb09"}

We will use this virtctl command-line utility in the next section.

Now that you are outfitted with the proper command-line tools, it’s time to prepare your network for the incoming deployment. This will ensure that the firewall can be implemented successfully and without any nagging errors. 

Network preparation

Follow these steps to begin preparing your network:

1. Make sure that the NMState Operator is installed within the OpenShift environment, and that there are working NodeNetworkConfigurationPolicy (NNCP) and NetworkAttachmentDefinition (NAD) definitions which can be used for this section. Examples will be provided below.
   
   As an example, an unused secondary interface named “eno8303” will be used throughout this section. A bridge will be created on this device, which will allow multiple VLANs to be terminated as access ports to OpenShift Virtualization hosts. Most administrators will understand this to be a “trunk port”. The NodeNetworkConfigurationPolicy below will define this “trunk port” and the NetworkAttachmentDefinition manifests will break out each of the VLANs for the Palo Alto VM-Series firewall interfaces.
   
   Let’s start with the NodeNetworkConfigurationPolicy:

   # Edit the following YAML according to your environment:
   ---
   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     annotations:
       description: Trunk port bridge for breaking out VLANs
    name: eno8303-br0
   spec:
     desiredState:
       interfaces:
         - bridge:
             options:
               stp:
                 enabled: false
             port:
               - name: eno8303
           description: "Bridge for PAN-OS demonstration on NIC eno8303"
           ipv4:
             enabled: false
           mtu: 1500
           name: eno8303-br0
           state: up
           type: linux-bridge
     nodeSelector:
       node-role.kubernetes.io/worker: ''

2. With the main bridge port created on interface eno8303 (remember, think of this as a “trunk port” bridge), you can now create multiple NetworkAttachmentDefinition definitions which represent each of the VLANs we’ll want the VM-Series firewall to protect. Using some more examples (i.e., VLANs 3, 30, 90, and 31) let’s create these now. Here’s an overview description of each of their roles (Management, Trust, Untrust, and DMZ):

   • vlan3: Management
   • vlan30: Trust
   • vlan31: DMZ
   • vlan90: Untrust

   Hint: One thing to note below is that we’re deploying the NetworkAttachmentDefinition manifests in the same namespace where the firewalls will be deployed. This is typically recommended as a best practice, but if you want these networks to be available for all namespaces, you can place them into the default namespace. While NADs are namespaced, keep in mind that NNCPs are not; these are global.

   Here is the example manifest for the Management network (vlan3):

   $ export namespace=demo-pan
   
   # Edit the following YAML according to your environment:
   ---
   apiVersion: k8s.cni.cncf.io/v1
   kind: NetworkAttachmentDefinition
   metadata:
     annotations:
       description: "Corporate vlan3 access NAD: Management" 
       k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/eno8303-br0
     name: vlan3
     namespace: $namespace
   spec:
     config: |
       {
         "cniVersion": "0.3.1",
         "name": "vlan3",
         "type": "bridge",
         "bridge": "eno8303-br0",
         "macspoofchk": true,
         "vlan": 3
       }

Here is the example manifest for the Trust network (vlan30):

$ export namespace=demo-pan

# Edit the following YAML according to your environment:
---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    description: "Corporate vlan30 access NAD: Trust" 
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/eno8303-br0
  name: vlan30
  namespace: $namespace
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "vlan30",
      "type": "bridge",
      "bridge": "eno8303-br0",
      "macspoofchk": true,
      "vlan": 30
    }

Here is the example manifest for the Untrust network (vlan90):

$ export namespace=demo-pan

# Edit the following YAML according to your environment:
---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    description: "Corporate vlan90 access NAD: Internet" 
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/eno8303-br0
  name: vlan90
  namespace: $namespace
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "vlan90",
      "type": "bridge",
      "bridge": "eno8303-br0",
      "macspoofchk": true,
      "vlan": 90
    }

Finally, here is the example manifest for the DMZ network (vlan31):

$ export namespace=demo-pan

# Edit the following YAML according to your environment:
---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    description: "Corporate vlan31 access NAD: DMZ" 
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/eno8303-br0
  name: vlan31
  namespace: $namespace
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "vlan31",
      "type": "bridge",
      "bridge": "eno8303-br0",
      "macspoofchk": true,
      "vlan": 31
    }

After deploying each of these (according to your own needs), we can move on to creating the firewall virtual machine.