>
    Strata Copilot
    Prerequisites
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma AIRS
    3. AI Runtime Security
    4. AI Runtime Security VM Firewall
    5. Cloud IP-Tag Harvesting: Public Kubernetes Cluster Support
    6. Prerequisites
    Download PDF
    Prisma AIRS

    Prerequisites

    Table of Contents

    Prerequisites

    Grant the permissions and network access that Strata Cloud Manager needs to harvest IP-tags from public EKS, GKE, and AKS clusters.
    Where Can I Use This?What Do I Need?
    • Prisma AIRS - AI Runtime Security
    • Cloud account onboarded in Strata Cloud Manager
    • Edit access to the EKS, GKE, AKS cluster
    The identity that requires Kubernetes permissions depends on how you onboarded the cloud account in SCM:
    CloudOnboarded with TerraformOnboarded with access keys
    AWSCloud IP-Tag IAM role created by the TerraformThe IAM user whose access key was entered
    GCPCloud IP-Tag service account created by the TerraformThe service account in the uploaded JSON key
    AzureCloud IP-Tag app registration created by the TerraformThe app registration whose client ID was entered
    For IAM user-based onboarding (AWS access keys), replace role/<cloud-ip-tag-role> with user/<name> in the --principal-arn CLI argument.

    Allowlist IP addresses (conditional)

    This step is not required if your cluster's API server endpoint is open to all IP addresses, which is the default on all three cloud providers. If your cluster's API server endpoint is restricted to specific IP ranges, add both Palo Alto Networks IP addresses for your SCM tenant region before monitoring can begin.
    Use your SCM Tenant Region, not the region where the cluster is running.
    Tenant RegionRequired IP Addresses
    United States35.192.176.130/32, 34.72.71.159/32
    Netherlands (EU)34.90.193.3/32, 34.90.233.216/32
    Add the IPs using the console path for your cloud provider:
    • EKS: Cluster → Networking → Public access source allowlist
    • GKE: Cluster → Control plane authorized networks
    • AKS: Cluster → Networking → API server authorized IP ranges

    Terraform onboarding

    If you onboarded your cloud accounts using Terraform, re-apply the latest Terraform templates to grant the necessary discovery permissions:
    • AWS: Adds eks:ListClusters and eks:DescribeCluster.
    • GCP: Adds roles/container.viewer.
    • Azure: Adds Microsoft.ContainerService/managedClusters/read and Microsoft.ContainerService/managedClusters/listClusterUserCredential/action.
    Limitations of Terraform coverage:
    • Terraform covers account-level permissions only. The per-cluster steps—EKS access entries, AKS custom role assignment or ClusterRole/ClusterRoleBinding, and API server IP allowlists—must always be performed manually.
    • Customers who onboarded using access keys (not Terraform) must grant these same permissions to the IAM user, service account, or app registration manually.
    If permissions are missing when you configure tag distribution in SCM, a warning banner prompts you to download and apply the updated Terraform script. After re-applying, the banner can take up to 24 hours to clear. VM monitoring is not affected while the banner is shown.

    Amazon EKS

    Perform the following steps for each EKS cluster you intend to monitor. Access entries are per cluster—for many clusters, script the CLI or use the Terraform resources aws_eks_access_entry and aws_eks_access_policy_association. No kubectl or ClusterRole step is required on EKS.
    • Set the cluster authentication mode to API or API_AND_CONFIG_MAP. CONFIG_MAP alone is not supported.
      • Console path: Cluster → Access → Authentication mode
      • AWS only allows changing the mode in one direction: CONFIG_MAP → API_AND_CONFIG_MAP → API.
    • Create an EKS Access Entry for the onboarded Cloud IP-Tag IAM Role or IAM User:
      • Access Policy: AmazonEKSAdminViewPolicy
        The built-in AmazonEKSViewPolicy is not sufficient—it excludes node permissions. Use AmazonEKSAdminViewPolicy.
      • Access Scope: Cluster
    Example AWS CLI commands
    aws eks create-access-entry --cluster-name <cluster-name> \
  --principal-arn arn:aws:iam::<account-id>:role/<cloud-ip-tag-role>

aws eks associate-access-policy --cluster-name <cluster-name> \
  --principal-arn arn:aws:iam::<account-id>:role/<cloud-ip-tag-role> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy \
  --access-scope type=cluster

    Google Cloud GKE

    Grant the roles/container.viewer role to the onboarded Cloud IP-Tag Service Account at the Project level. This single grant covers every cluster in the project and is already included in the updated Terraform template—Terraform customers only need to re-apply. If your clusters have Control plane authorized networks enabled, add both Palo Alto Networks IPs for your tenant region (see the allowlist table above).

    Azure AKS

    The approach depends on the cluster's Authentication and Authorization setting in the Azure portal. Select the option that matches your configuration:
    Cluster auth typeRequired action
    Microsoft Entra ID with Azure RBACAssign the custom role (Option A) at the Subscription or Resource Group level. One assignment covers every cluster in scope.
    Microsoft Entra ID with Kubernetes RBACApply the ClusterRole and ClusterRoleBinding (Option B) in each cluster.
    Local accounts (no Entra ID)Not supported.
    Option A — Azure RBAC: Custom role assignment
    Create a custom role with the following six data actions and assign it to the onboarded App Registration at the Subscription or Resource Group level. The built-in Azure Kubernetes Service RBAC Reader role is not sufficient.
    {
  "Name": "PANW K8s Watcher",
  "Description": "Read-only Kubernetes access for Palo Alto Networks Cloud IP-Tag",
  "AssignableScopes": ["/subscriptions/<subscription-id>"],
  "Actions": [],
  "DataActions": [
    "Microsoft.ContainerService/managedClusters/pods/read",
    "Microsoft.ContainerService/managedClusters/services/read",
    "Microsoft.ContainerService/managedClusters/endpoints/read",
    "Microsoft.ContainerService/managedClusters/nodes/read",
    "Microsoft.ContainerService/managedClusters/discovery.k8s.io/endpointslices/read",
    "Microsoft.ContainerService/managedClusters/authorization.k8s.io/selfsubjectaccessreviews/write"
  ]
}
    The sixth action is selfsubjectaccessreviews/write—not /create. The system runs a SelfSubjectAccessReview check before monitoring a cluster; without this permission, the check is denied and the cluster is never monitored. Azure role assignments can take up to approximately 10 minutes to take effect.
    Option B — Kubernetes RBAC: ClusterRole and ClusterRoleBinding (per cluster)
    Apply the following YAML in each cluster. Set the subject name to the App Registration client ID:
    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: panw-k8s-watcher
rules:
- apiGroups: [""]
  resources: ["pods", "services", "endpoints", "nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["discovery.k8s.io"]
  resources: ["endpointslices"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["authorization.k8s.io"]
  resources: ["selfsubjectaccessreviews"]
  verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: panw-k8s-watcher-binding
subjects:
- kind: User
  name: "<app-registration-client-id>"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: panw-k8s-watcher
  apiGroup: rbac.authorization.k8s.io

    © 2026 Palo Alto Networks, Inc. All rights reserved.