Configure Panorama to Secure a Kubernetes Deployment
Focus
Focus
CN-Series

Configure Panorama to Secure a Kubernetes Deployment

Table of Contents

Configure Panorama to Secure a Kubernetes Deployment

Set up your Panorama to connect to the Kubernetes clusters and retrieve the tags to secure traffic to pods within or outside the cluster.
Where Can I Use This?
What Do I Need?
  • CN-Series Firewall
    deployment
  • CN-Series 10.1.x or above Container Images
  • Panorama
    running PAN-OS 10.1.x or above version
  • Helm 3.6 or above version client
    for CN-Series deployment with helm chart
After you Install the Kubernetes Plugin for CN-Series and deploy the CN-Series firewall, to monitor the Kubernetes cluster and configure the Security policies that enable traffic enforcement, you need to complete the following tasks
  1. Verify that the CN-MGMT pods are registered on Panorama and the CN-NGFW pods are licensed.
    1. Select
      Panorama
      Managed Devices
      Summary
      .
    2. Select
      Panorama
      Plugins
      Kubernetes
      License Usage
      to verify that each node within the cluster is allocated a license token.
  2. Create a Log Forwarding profile to forward logs to Panorama.
    The profile defines the destinations for the different logs that will be generated on the firewall.
    1. Select the device group you created for the k8s deployment from the
      Device Group
      drop-down.
    2. Select
      Objects
      Log Forwarding
      and click
      Add
      .
    3. Enter a
      Name
      to identify the profile. If you want to automatically assign the profile to new security rules and zones, enter
      default
      . If you don’t want a default profile, or you want to override an existing default profile, enter a
      Name
      that will help you identify the profile when assigning it to security rules.
    4. Add
      the log types to forward.
    5. Click
      OK
      .
  3. Configure the Kubernetes plugin to push the tags to the specified device groups.
    You must add a monitoring definition that includes the name of the Kubernetes cluster from which Panorama retrieves predefined labels and optionally a notify group.
    A notify group is required if the CN-Series is deployed in a namespace other than kube-system.
    A notify group is a list of device groups that receive tag updates. For the Kubernetes plugin, the notify group should include firewalls external to the cluster (meaning that they do not belong to the same device group as the Kubernetes cluster from which you are collecting attributes).
    Because you specify the device group name in the YAML files that are used to deploy the CN-Series firewalls, the Kubernetes plugin automatically learns of all device groups that are internal to the cluster and it automatically pushes all predefined tags to those device groups by default.
    The Kubernetes plugin uses Kubernetes Secrets to dynamically learn of the device groups within each cluster. Each time you deploy a CN-MGMT StatefulSet, the Secret is published to the Kubernetes API server and Panorama learns of it in the next monitoring interval.
    1. Add notify groups. Add a notify group and select the device groups that receive the tags related to your Kubernetes cluster.
      1. Select
        Panorama
        Plugins
        Kubernetes
        Setup
        Notify Groups
        , and
        Add
        .
      2. Enter a
        Name
        of up to 31 characters for the notify group.
      3. Select
        Enable sharing internal tags with Device Groups
        if you want to share internal tags in addition to the external tags (default) created for the cluster.
      4. Select the device groups to which you want to register the tags.
        For the Notify Group that you select, Panorama only pushes the external tags.
        An external tag is any tag that is reachable from outside the cluster such as tags generated for an external service IP address and port for a cluster IP address, external IP address for all nodes and node ports, and external load balancer IP address and port or node port.
        The internal tags include details on the internal cluster IP addresses, pod IP address, nodes and node ports.
        By default, Panorama pushes all the tags it discovers (based on the Label Filters you select) to the Device Group associated with the cluster as defined in the YAML file that you used to deploy the CN-MGMT pods.
    2. Add a Monitoring Definition for each cluster.
      1. Select
        PanoramaPlugins
        Kubernetes
        Monitoring Definition
        and
        Add
        .
      2. Enter a
        Name
        for the monitoring definition.
      3. Select the
        Cluster
        you want to monitor.
      4. (
        Optional
        ) Select a
        Notify Group
        to which you want to send the IP-address-to-tag mapping information.
        By default the tags are shared with all CN-NFGW pods within the cluster.
      5. Click
        OK
        to save your changes.
    3. Commit
      to Panorama.
  4. (
    Optional
    ) Set up the Kubernetes plugin to retrieve user-defined labels from your application YAML files.
    1. Select
      PanoramaPlugins
      Kubernetes
      Setup
      Cluster
      , and select the cluster definition from the list.
    2. Select the label filter from the following options:
      1. No Labels
        —Does not create any tags for Kubernetes labels.
      2. Custom Labels
        —Creates tags for only the labels you care about.
        To use custom labels, you must first annotate the YAML files inyour Kubernetes deployment, and then use any of the followingcombinations to generate custom tags for the corresponding IPaddresses:
        Specify the namespace, key, and value. Use * for all. The plugincreates tags when all three inputs are valid.
        Specify the namespace, and key, to create tags for allmatching keys within that namespace.
        Specify the namespace only to create a tag for every label withinthat namespace.
      3. Select All Labels
        —Create tags for all Kubernetes labels including any custom labels.
    3. Add a label selector expression.
      The label selector matches the specified label within the Kubernetes cluster and maps the IP addresses associated with the label to a single tag. For a list of supported prefixes see IP-Address-to-Tag Mapping of Kubernetes Attributes.
      For each label selector, Panorama generates a tag that becomes available as match criteria in dynamic address groups and enable you to enforce security policies:
      1. Tag Prefix
        —Phrase that each tag ends with to help you easily identify the tag. For example, the label selector k8s.cl_<clustername>.<selector-name>, matches on all ClusterIPs that match theselector, all Pod IPs that match the selector. These could be in all namespaces or specific one depending on what you configure.
      2. Namespace
        — * for all namespaces, or enter a value for the namespace.
      3. Label Selector Filter
        —The Kubernetes plugin supports set-based and equality-based selectors for label key and label value. The following equality-based selectors are supported —key = value; key ==value; key != value, for example, app = redis. You can also specify multiple selectors in an expression as a comma separated list, such as app == web, tier != backend. The following set-based selectors are supported—key in (value1,value2), key notin (value1, value2), key, !key, for example, tier notin (frontend, backend).
      4. Apply On
        —The type of resource to apply this on is Service, Pod, All.
  5. Set up the Dynamic Address Groups.
    1. Select your Device Group for managing the CN-NGFW pods.
    2. Select
      Objects
      Address Groups
      .
    3. Click
      Add
      and enter a
      Name
      and a
      Description
      for the address group.
    4. Select
      Type
      as
      Dynamic
      .
  6. Click
    Add Match Criteria
    , and select the
    AND
    or
    OR
    operator and select the attributes that you would like to filter for or match against.
  7. Click
    OK
    and
    Commit on Panorama
    .
    Use the
    more...
    link to view the IP addresses associated with the object, the Jenkins servers in your cluster in this example.
  8. Create Security Policy rules for traffic enforcement.
    1. Select
      Policies
      Security
      .
    2. Click
      Add
      and enter a
      Name
      and a
      Description
      for the policy.
    3. Add the
      Source Zone
      to specify the zone from which the traffic originates.
    4. Add the
      Destination Zone
      at which the traffic is terminating.
    5. For the
      Destination Address
      , select the Dynamic address group you just created.
    6. Specify the action—
      Deny
      —for the traffic, and optionally attach the default security profiles to the rule.
    7. Select
      Actions
      and select the
      Log Forwarding
      profile you created.
    8. Click
      Commit
      .
      You can also apply Security policy for east-west traffic within namespaces. If for example, you have two namespaces stage-ns and db-ns within a cluster named staging cluster where the frontend pods for a voting application are deployed in stage-NS, and the Redis backend pods are running in the DB-NS namespace. When you add this cluster to the Kubernetes plugin on Panorama for monitoring, it retrieves the label metadata to create tags. You can use these tags to enforce Security policy rules. To do this you need to
      • Make sure that the Namespace or YAML files you use to deploy the frontend and backend applications are annotated with paloaltonetworks.com/firewall: pan-fw.
      • Create the dynamic address group for the frontend and the backend pods.
        You must configure the dynamic address groups in the device group associated with the cluster, and select the tags for the frontend servers first. Then, repeat the process to create another dynamic address group for the backend servers.
      • Add the Security policy rule to allow traffic for the Redis app from the frontend pods to backend pods.
        The source is the dynamic address group of the frontend servers and the destination is the dynamic address group for the backend servers, and the action is allow.

Recommended For You