Configure Panorama to Secure a Kubernetes Deployment

1. Verify that the CN-MGMT pods are registered on Panorama and the CN-NGFW pods are licensed.

   1. Select PanoramaManaged DevicesSummary.

   2. Select PanoramaPluginsKubernetesLicense 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 ObjectsLog 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. Set up the kubernetes plugin for monitoring the clusters.
   2. Add notify groups. Add a notify group and select the device groups that receive the tags related to your Kubernetes cluster.

      1. Select PanoramaPluginsKubernetesSetupNotify 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.
   3. Add a Monitoring Definition for each cluster.

      1. Select PanoramaPluginsKubernetesMonitoring 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.
   4. Commit to Panorama.
4. (Optional) Set up the Kubernetes plugin to retrieve user-defined labels from your application YAML files.

   1. Select PanoramaPluginsKubernetesSetupCluster, 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 ObjectsAddress 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 PoliciesSecurity.
   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.