Components Required to Secure Kubernetes Clusters with CN-Series Firewall

Know what components you need to deploy the CN-Series in your Kubernetes clusters.
The following is a list of what you need to Deploy the CN-Series Firewalls and secure the applications deployed within Kubernetes clusters.
  • Panorama
    —A hardware-based or virtual appliance that can connect to the Kubernetes clusters where the applications and CN-Series firewalls are deployed. Panorama is required for license management and configuration management of the CN-Series firewalls. For more information, see CN-Series Core Building Blocks.
  • Kubernetes Plugin on Panorama
    —Because of the rate of change with containerized applications, this plugin is required for visibility into container activity within a cluster and for managing the license token allocation for the firewall deployed on each node within a cluster.
    The Kubernetes plugin connects to Kubernetes clusters using service account credentials. From there it retrieves resource attributes and labels and creates tags and service objects. The tags can be used to create Dynamic address groups and reference them in Security policy for IP traffic enforcement. You can also use the service objects in Security policy to allow or deny traffic based on ports as well as IP addresses. The tags and service objects give you visibility and granular control for traffic enforcement within your Kubernetes cluster.
  • Docker Images
    —To support the distributed architecture, the CN-Series firewall has four docker images that are available on the Palo Alto Networks Customer Support Portal (CSP). These images are published as three compressed tar archives (tar.gz format), and you must get these images unzip and do a Docker push to your image registry.
    Note:
    Make sure that the images and YAML files versions are compatible.The compressed files are:
    • PanOS_cn-10.1.0.tgz
      —This archive includes the firewall management plane (CN-MGMT) and firewall dataplane (CN-NGFW) images.
      The unzipped image names are, for example:
      panos_cn_ngfw:10.0.0-b7
      and
      panos_cn_mgmt:10.0.0-b7
      • Pan_cn_mgmt_init-2.0.0.tgz
        —This archive includes the init container (CN-INIT) that contains the utilities required to deploy the management plane on the firewall. The init container enables secure IPSec communication between the CN-MGMT and CN-NFGW Pods. The unzipped image name is for example:
        pan_cn_mgmt_init:1.0.0-b1-c1
        .
      • Pan_cni-2.0.0.tgz
        —This archive includes the CNI plugin that enables connectivity between the CN-MGMT and CN-NFGW and reconfigures the network interfaces on the application pods to redirect traffic to the CN-NGFW pod on each node. The unzipped image name is for example:
        pan_cni:2.0.0
        .
  • YAML Files
    —The YAML files that include the required fields and object specifications for deploying the resources in your Kubernetes clusters, and are published on GitHub.
    All the YAML files you need, for a supported environment such as native Kubernetes or GKE, are combined and zipped in one folder for your convenience.
    • CN-MGMT has three YAML files—
      pan-cn-mgmt.yaml
      ,
      pan-cn-mgmt-configmap.yaml
      ,
      pan-cn-mgmt-secret.yaml
      ,
      pan-cn-mgmt-slot-cr.yaml
      , and
      pan-cn-mgmt-slot-crd.yaml
      .
    • CN-NGFW as a DaemonSet has two YAML files—
      pan-cn-ngfw.yaml
      , and
      pan-cn-ngfw-configmap.yaml
      . The CN-NGFW as a Kubernetes Service has
      pan-cn-ngfw-svc.yaml
      in addition to the previously mentioned files.
    • CNI plugin has three YAML files—
      pan-cni-configmap.yaml
      and
      pan-cni.yaml
      or
      pan-cni-multus.yaml
      .
      If you are deploying the CN-Series on environments with the Multus CNI that acts as a
      meta-plugin
      , and calls other CNI plugins you have to choose either
      pan-cni.yaml
      or
      pan-cni-multus.yaml
      .
      When deploying the CN-Series on OpenShift, Multus is enabled by default, the pan-cni.yaml is adequate. Whereas, if you are deploying the CN-Series on an environment where the Multus CNI is supported but is optional such as with self-managed (native) environments, use the pan-cni-multus.yaml instead of the pan-cni.yaml.
      • There is also a
        pan-cni-serviceaccount.yaml
        that is referenced in the service account creation section below.
      • For OpenShift deployments there is an additional
        pan-cni-net-attach-def.yaml
        .
    • Service Account Creation
      —Three YAML files,
      pan-mgmt-serviceaccount.yaml
      ,
      pan-cni-serviceaccount.yaml
      , and
      plugin-serviceaccount.yaml
      .
      pan-mgmt-serviceaccount.yaml
      and
      pan-cni-serviceaccount.yaml
      are for the CN-MGMT and CN-NGFW pods to authenticate to the cluster.
      The
      plugin-serviceaccount.yaml
      is for the Kubernetes plugin on Panorama to authenticate to the cluster.
    • Persistent volume YAML for Native Kubernetes deployments
      pan-cn-pv-manual.yaml
      and
      pan-cn-pv-local.yaml
      .
      The
      pan-cn-pv-manual.yaml
      is only provided for PoC with single node clusters. Palo Alto Networks strongly recommends the use of dynamically provisioned persistent volumes for storing the configuration and logs for the CN-MGMT pods that are referenced in the
      pan-cn-mgmt.yaml
      . Make sure to set up a persistent volume within the cluster for both the CN-MGMT pods.
  • License auth code
    —The auth code enables you to license each instance of the CN-NGFW pod deployed on each node within a cluster.
    The license auth code is tied to the CN-Series license bundle you purchased. You must provide the license bundle information in the
    pan-cn-mgmt-configmap.yaml
    and the corresponding auth code on the Panorama (Kubernetes plugin) in order to ensure that the CN-NGFW pods can register with the CN-MGMT pods, which communicates with Panorama.
    If the license bundle and auth code do not match, licensing will fail and you will need to redeploy the CN-MGMT pods with the correct license bundle and auth code combination. For more information about licenses, see License the CN-Series Firewall.
    Note the following details when your license information is updated on a renewal, mid-term upgrade, or expiration:
    • Renewals- When you renew your existing bundle licenses, if you upgrade or downgrade the license bundles, you must delete the existing deployment, and redeploy the firewalls.
    • Mid-term upgrade- On a mid-term upgrade you can increase the quantity of tokens associated with your auth code or upgrade the subscription bundle (for example Basic to Bundle 1 or Bundle 1 to Bundle 2). When you upgrade the subscription bundle, you must delete the existing deployment, and redeploy the firewalls for using the additional subscriptions that you have purchased.
    • License Expiration-If your license expires and you do not renew it within the 30-day grace period, the licenses are deactivated. The CN-NGFW pods use the failover mode—failopen or failclosed—as defined in your PAN-CN-MGMT-CONFIG yaml. You must renew the license, register it on the CSP, and redeploy the firewalls.

Recommended For You