Verify that the CN-MGMT pods are registered on
Panorama and the CN-NGFW pods are licensed.
to verify that
each node within the cluster is allocated a license token.
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.
Select the device group you created for
the k8s deployment from the
to identify the
profile. If you want to automatically assign the profile to new
security rules and zones, enter
If you don’t want a default profile, or you want to override an
existing default profile, enter a
will help you identify the profile when assigning it to security
the log types to forward.
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
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).
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.
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.
Add notify groups. Add a notify group and select the device groups that
receive the tags related to your Kubernetes cluster.
of up to 31 characters
for the notify group.
Enable sharing internal tags with Device
if you want to share internal tags in
addition to the external tags (default) created for the
Select the device groups to which you want to register the
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.
Add a Monitoring Definition for each cluster.
for the monitoring definition.
you want to monitor.
) Select a
which you want to send the IP-address-to-tag mapping information.
default the tags are shared with all CN-NFGW pods within the cluster.
to save your changes.
) Set up the Kubernetes plugin to retrieve
user-defined labels from your application YAML files.
, and select the cluster
definition from the list.
Select the label filter from the following options:
—Does not create any tags for Kubernetes 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.
namespace only to create a tag for every label withinthat namespace.
Select All Labels
—Create tags for
all Kubernetes labels including any custom labels.
each label selector, Panorama generates a tag that becomes available
as match criteria in dynamic address groups and enable you to enforce
—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.
— * for all namespaces, or enter a value
for the namespace.
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).
—The type of resource to apply this on is Service,
Set up the Dynamic Address Groups.
Select your Device Group for managing the
and enter a
for the address group.
Add Match Criteria
and select the attributes that you would like to filter for or match
to view the IP addresses associated with the object, the Jenkins
servers in your cluster in this example.
Create Security Policy rules for traffic enforcement.
and enter a
for the policy.
the zone from which the traffic originates.
which the traffic is terminating.
select the Dynamic address group you just created.
Specify the action—
the traffic, and optionally attach the default security profiles
to the rule.
and select the
profile you created.
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
sure that the Namespace or YAML files you use to deploy the frontend
and backend applications are annotated with paloaltonetworks.com/firewall:
Create the dynamic address group for the frontend and the backend
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.