Configure IP-Tag Collector to Send IP-Tags to Edge Service for Public Cluster

1. Onboard the Service Account for your cloud provider.

   Onboard your cloud account

   When onboarding using Terraform, the SCM wizard displays a downloadable .zip package containing the Terraform template. In AWS, after running terraform apply in your cloud CLI/console, copy the generated terminal outputs—such as the IAM Role ARN —and paste them back into the corresponding fields in the SCM wizard to finalize authentication. In GCP or Azure cloud environment, ensure that you apply the terraform and then click save configuration.

2. Configure Tag Distribution

   1. Under IP Collection for Cloud Services, locate your onboarded cloud account.
   2. Click Distribute (or Edit an existing distribution).
   3. Enter General Info:

      • Enter a Tag Distribution Name.
      • Select Cloud Service via API as the Tag Collection Type.
      • Select Resources to monitor:
        • VM Workload: Monitor virtual machine instances only.
        • Public Cluster: Monitor public Kubernetes clusters only.
        • Both: Monitor both VM workloads and public Kubernetes clusters under the same account.
      • Polling Interval: The polling interval (60–1,800 seconds) applies to VM workloads only. Kubernetes monitoring is event-driven—pod and service changes reach the firewall within seconds, and new clusters or permission changes are picked up within approximately 15 minutes. Lowering this value does not speed up Kubernetes tag updates.
   4. In the Select Tag Source section, select your cluster.

      When Public Cluster or Both is selected, choose how clusters are targeted. In every mode, a cluster is monitored only after its prerequisites are in place and the system can successfully reach the API server. Only clusters that are ready are harvested and displayed for manual selection. If a monitored cluster later loses permissions, it remains selected, but monitoring is paused; monitoring resumes automatically (within approximately 15 minutes) once permissions are restored. One cluster can be included in more than one tag distribution.

      • All Clusters: Automatically monitors every discovered public cluster in the onboarded account.
      • Choose Specific Clusters (Manual): Select specific clusters from the drop-down list of discovered clusters.
      • Match Clusters with Labels: Define key-value filters against cloud-level resource tags (EKS resource tags, GKE cluster labels, or AKS resource tags)—not Kubernetes labels on pods or namespaces. Only clusters matching all specified pairs are monitored. Matching is exact and case-sensitive on both key and value. An empty value matches only an empty tag value, not all values. New clusters that gain matching tags are picked up automatically.
   5. Select Tag Destination: Select the target Firewall Folders where the harvested IP-tag mappings should be pushed. Firewalls must already be placed in the folder before tags can be distributed to them.
   6. Click Save the Configuration.
3. Verification & Tag Mapping Overview

   1. Go to Tag Mapping State under the IP Collection dashboard.
   2. Select your distribution or cluster to view collected tags.
   3. Generated Tag Structure: Kubernetes tags are formatted automatically using the k8s. prefix.

   Tag format conventions:

   • <cl> is the cluster name (not the cluster ID or ARN).
   • Custom pod labels: a label app=web becomes k8s.app.web.
   • k8s.svc_<name> is applied to both the service cluster IP and its backend pod IPs, so one policy rule covers both.
   • Spaces in tags are replaced with _.
   • Tags longer than 127 characters are shortened and receive a hash suffix.
   • Pods in the Succeeded or Failed phase are not tagged.

   Full tag reference:

   IP Address Type	Tags Generated
   Pod IP	k8s.cl_<cl>, k8s.ns_<ns>, k8s.cl_<cl>.ns_<ns>; owner tags: k8s.ds_<name> (Deamonset), k8s.ss_<name> (StatefulSet), or k8s.rs_<name> (ReplicaSet), plus full-form variant k8s.cl_<cl>.ns_<ns>.ds_<name>; per pod label: k8s.<key>.<value> and k8s.cl_<cl>.ns_<ns>.<key>.<value>
   Service cluster IP	k8s.ns_<ns>, k8s.svc_<name>, k8s.cl_<cl>.ns_<ns>, k8s.cl_<cl>.ns_<ns>.svc_<name>, plus service labels and selector labels in k8s.<key>.<value> format
   Service external IP (LoadBalancer / externalIPs)	k8s.exsvc_<name>, k8s.cl_<cl>.ns_<ns>.exsvc_<name>
   Endpoint IPs (pods backing a service)	k8s.ns_<ns>, k8s.svc_<name>, k8s.cl_<cl>.ns_<ns>.svc_<name>
   Node internal IP	k8s.nodes, k8s.cl_<cl>.nodes
   Node external IP	k8s.ex_nodes, k8s.cl_<cl>.ex_nodes

   Example policy destinations:

   Goal	Tag to reference in policy destination
   Allow traffic to a LoadBalancer service (external IP)	k8s.exsvc_<service-name>
   Allow traffic to pods with label app=web	k8s.app.web
   Allow traffic to all pods in a namespace	k8s.ns_<namespace>
   Allow traffic to all nodes in a cluster	k8s.cl_<cl>.nodes

   If an access entry or permission is configured after setting up tag distribution, the system reconciles automatically and begins harvesting tags within approximately 15 minutes. No manual configuration restart is required.

   Important Considerations:

   • Read-only access: The system never modifies anything in your clusters.
   • Removing access removes tags: If an access entry, custom role, or ClusterRole is removed, or if the onboarded credential stops working (for example, a role is deleted or trust is revoked), the cluster stops being monitored and its tags are withdrawn from your firewalls. Temporary network problems and timeouts do not remove tags.
   • Deleted clusters stop being monitored automatically.
   • IP-tag pruning: With pruning enabled, only Kubernetes tags referenced in your security policies are distributed to firewalls—the same behavior as for VM workloads. The Tag Mapping State view may show fewer tags than are generated.
   • Per-cluster status: The Connection/Sync status columns in the UI reflect VM regions only. Per-cluster Kubernetes status is not available in this release.