> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/kubernetes-security/kubernetes-resources-inventory/kubernetes-pods.md). # Kubernetes pods Kubernetes security provides comprehensive support for pods, including inventory tracking, detailed asset visibility, compliance scanning, and container inspection. This enhances protection across your workloads, whether they are managed by a controller (such as a deployment or job), deployed directly as standalone pods, or modified during admission before they run. Kubernetes security models the actual running pod, showing you the workload exactly as it operates in the cluster, including any changes applied after its definition. Support for pods is available through the Posture Management solution of the Kubernetes Security offering. To collect pods, install either the agent-based Kubernetes Connector or Agentless KSPM. Pods are where your workloads actually run. By modeling both directly, Kubernetes security gives you a complete, instance-level view of your clusters: * See the real running state of every workload, not only its desired state as defined by the controller. * Extend security coverage to workloads deployed directly as pods, for example, with `kubectl apply -f pod.yaml`, so standalone workloads are fully represented alongside managed ones. * Assess and prioritize risk at the container-instance level, providing your teams with precise context for investigation and remediation. Key benefits include: * **Complete visibility**: A dedicated **Kubernetes Pod Group** in the inventory includes a relationship graph that shows how a pod connects to related Kubernetes resources. **Kubernetes Pod Groups** are also available in **Search Graph** for discovery and investigation. * **Container inspection:** A **Containers** tab on each **Kubernetes Pod Group** asset provides complete visibility into pod composition and container details, including each container's name, image, exposed ports, command, arguments, and **Container type**: **Main** (your application's primary container), **Init** (runs to completion before the main container starts), or **Sidecar** (a helper container that runs alongside the main container). You can filter the **Containers** tab to focus on specific containers and export the container data for reporting or offline analysis. Use the **Kubernetes Pod Group** to investigate the security posture of individual pods and their containers. * **Compliance and rules**: Run compliance checks on pods alongside workload controllers, including system-rule validation for pod-scoped Rego rules. Custom compliance rules also support pods. * **Scalable by design**: Identical replicas are automatically aggregated into a single **Kubernetes Pod Group** asset, so you gain full visibility without inventory clutter in large clusters. **Kubernetes Pod Group** aggregation is available for both the Kubernetes connector (agent) and Kubernetes agentless deployments. Standalone pods and pods owned by unsupported kinds (for example, Node-owned static pods) each produce their own single-replica **Kubernetes Pod Group** with **Is Standalone** = true. Agentless deployments collect pods that are linked to a controlling workload. ### Kubernetes Pod Group Kubernetes clusters can run thousands of pods, most of which are identical replicas of the same workload. To keep your inventory clear and eliminate clutter, Kubernetes security automatically aggregates identical pods into a single **Kubernetes Pod Group** asset. When you access **Kubernetes Resources** in the **Kubernetes Resources** page, you can filter by the **Kubernetes Pod Group** type to view these assets. Each **Kubernetes Pod Group** reports the following properties: * **Replicas**: The number of identical pods aggregated into the group. * **Is Standalone**: Indicates whether the pod was created directly (with no controlling owner) or is managed by a controller. * **Containers**: Details on the containers running in the pod, including name, image, exposed ports, commands, arguments, and container type (**Main**, **Init**, or **Sidecar**). With the Kubernetes connector, standalone pods and pods owned by unsupported resource types are represented individually so nothing is hidden from the inventory. {% hint style="info" %} A **Kubernetes Pod Group** asset represents all identical Pod replicas of a workload as a single, unique inventory asset based on the workload owner's unique identifier. {% endhint %} ### Relationships graph for Kubernetes Pod Groups in Search Graph **Kubernetes Pod Groups** participate in the **Search Graph** asset relationship graph like other workloads. In addition to standard workload relationships, they include the following: * **Owned by**: Links a **Kubernetes Pod Group** to its controlling workload (ReplicaSet, StatefulSet, DaemonSet, or Job). * **Runs**: Links the **Kubernetes Pod Group** to the container images it runs. * **Routes traffic to/selected by**: Services and NetworkPolicies that target the workload also resolve to the corresponding **Kubernetes Pod Group**. {% hint style="info" %} **Note**: These relationships are available in **Search Graph** only. {% endhint %} Selecting a **Kubernetes Pod Group** in the **Kubernetes Resources** inventory opens its asset card, where you can review its overview, configuration, containers, security findings, and relationships within the cluster. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/kubernetes-security/kubernetes-resources-inventory/kubernetes-pods.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.