Identify & Evaluate Images In Kubernetes Clusters

Identifying and analyzing images running in a Kubernetes cluster

Summary

This quickstart page outlines how Anchore Enterprise integrates directly with Kubernetes environments to support continuous security and operational assurance. By connecting the Kubernetes Inventory Agent and running it in your cluster, Anchore Enterprise collects a real-time software inventory of running workloads, aligning containerized operations with vulnerability detection, configuration assessment, and policy controls.

As organizations scale Kubernetes deployments, Anchore Enterprise enables continuous monitoring of runtime images, automated policy evaluation, and actionable reporting to strengthen workload hardening and operational compliance. Through runtime inventory and policy enforcement, teams can standardize security across clusters, surface risk early, and ensure that live container images meet organizational and regulatory requirements.

Prerequisites

  • Anchore Enterprise deployed and accessible.
  • kubectl configured for your target Kubernetes cluster.
  • Cluster access with sufficient privileges to deploy agents.
  • Helm (optional, for easier deployment of the agent).

Connect the Kubernetes Inventory Agent

The Anchore Kubernetes Inventory Agent gathers information about running images and resources via an agent running inside your cluster.

To deploy the agent and begin monitoring your cluster;

  1. Add Anchore’s Helm repository:
helm repo add anchore https://charts.anchore.io
helm repo update
  1. Create a native user in Anchore that is uses the inventory-agent role permissions.

User Roles

  1. Build your values.yaml file by setting your username, password, Anchore Enterprise URL and cluster name:
k8sInventory:
  # Path should not be changed, cluster value is used to tell Anchore which cluster this inventory is coming from
  kubeconfig:
    cluster: <unique-name-for-your-cluster>
  
  anchore:
    url: <URL for your deployment>
    # Note: recommend using the inventory-agent role
    user: <user>
    password: <password>
  1. Install the Kubernetes Inventory Agent using Helm and the values file we just built:
helm install <release> -f <values.yaml> anchore/k8s-inventory

After deployment, verify the pod is up and running:

kubectl get pods -n anchore

The agent will automatically:

  • Discover all running pods and containers.
  • Collect image metadata and digest information.
  • Submit inventory to Anchore Enterprise.

Verification & Best Practices

Once your cluster is connected, verify agent connectivity by checking the logs to confirm it’s reporting inventory and status as expected:

kubectl logs -n anchore <inventory-agent-pod>

Viewing the Vulnerability Results of Running Images

  1. Log in to the Anchore Enterprise UI.

  2. Navigate to the Kubernetes tab to access your running cluster data. Be aware that you may need to wait for a brief period for discovered data to appear.

Cluster Namespaces

  1. Select your desired cluster. From here, You will get a real-time snapshot of what images are running and also be able to view:
  • The complete list of the running container images currently in use.
  • Vulnerabilities associated with each image, mapped to known CVEs.
  • CVSS scoring, severity distribution, and other helpful risk indicators so you can quickly spot anything that needs attention.

Running Inventory

Viewing and Enforcing Policy Evaluations

Anchore Enterprise also lets you apply and enforce security policies directly against your running images—so you’re not just observing problems, you’re controlling them.

  1. In the UI, go to Policies → Evaluation.

  2. Choose the policy bundle you want to assess or enforce (for example, minimum CVSS severity thresholds, banned packages, or disallowed images).

  3. Review the results, including:

  • Pass/Fail status for each image or cluster.
  • Detailed reasoning for policy violations, helping to guide remediation.
  1. Optionally - if you want to take things a step further, configure notifications or enforcement actions (e.g., blocking deployment of non-compliant workloads) to keep risky images out of production.
Last modified January 13, 2026