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.
After you Install the Kubernetes Plugin and Set up Panorama for CN-Series and Deploy the CN-Series Firewalls, to monitor the Kubernetes cluster and configure the Security policies that enable traffic enforcement, you need to complete the following tasks.
- Verify that the CN-MGMT pods are registered on Panorama and the CN-NGFW pods are licensed.
- Select.PanoramaManaged DevicesSummary
- Selectto verify that each node within the cluster is allocated a license token.PanoramaPluginsKubernetesLicense Usage
- 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 theDevice Groupdrop-down.
- Selectand clickObjectsLog ForwardingAdd.
- Enter aNameto identify the profile. If you want to automatically assign the profile to new security rules and zones, enterdefault. If you don’t want a default profile, or you want to override an existing default profile, enter aNamethat will help you identify the profile when assigning it to security rules.
- Addthe 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 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.
- Add notify groups.Add a notify group and select the device groups that receive the tags related to your Kubernetes cluster.
- Select, andPanoramaPluginsKubernetesSetupNotify GroupsAdd.
- Enter aNameof up to 31 characters for the notify group.
- SelectEnable sharing internal tags with Device Groupsif you want to share internal tags in addition to the external tags (default) created for the cluster.
- 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.
- Add a Monitoring Definition for each cluster.
- SelectandPanoramaPluginsKubernetesMonitoring DefinitionAdd.
- Enter aNamefor the monitoring definition.
- Select theClusteryou want to monitor.
- (Optional) Select aNotify Groupto 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.
- ClickOKto save your changes.
- Committo Panorama.
- (Optional) Set up the Kubernetes plugin to retrieve user-defined labels from your application YAML files.
- Select, and select the cluster definition from the list.PanoramaPluginsKubernetesSetupCluster
- Select the label filter from the following options:
- No Labels—Does not create any tags for Kubernetes labels.
- 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.
- Select All Labels—Create tags for all Kubernetes labels including any custom labels.
- 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:
- 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.
- Namespace— * for all namespaces, or enter a value for the namespace.
- Label Selector Filter—The Kubernetes plugin supports set-based andequality-based selectors for label key and label value. The followingequality-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 commaseparated list, such as app == web, tier != backendThe following set-based selectors are supported—key in (value1,value2), key notin (value1, value2), key, !key, for example, tier notin (frontend, backend).
- Apply On—The type of resource to apply this on is Service, Pod, All.
- Set up the Dynamic Address Groups.
- Select your Device Group for managing the CN-NGFW pods.
- Select.ObjectsAddress Groups
- ClickAddand enter aNameand aDescriptionfor the address group.
- ClickAdd Match Criteria, and select theANDorORoperator and select the attributes that you would like to filter for or match against.
- ClickOKandCommit on Panorama.Use themore...link 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.
- ClickAddand enter aNameand aDescriptionfor the policy.
- Add theSource Zoneto specify the zone from which the traffic originates.
- Add theDestination Zoneat which the traffic is terminating.
- For theDestination Address, select the Dynamic address group you just created.
- Specify the action—Deny—for the traffic, and optionally attach the default security profiles to the rule.
- SelectActionsand select theLog Forwardingprofile you created.
- ClickCommit.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
Recommended videos not found.