Kubernetes Runtime Inventory
This binary is installed into the Enterprise Docker Image and can be configured using the REST API, but depends on Anchore knowing your cluster configuration and corresponding credentials. On the other hand,
kai can also be run via it’s helm chart, embedded within your Kubernetes cluster as an agent. In this run-mode, it will require access to the Anchore API.
The most common way to track inventory is to install
kai as an agent in your cluster. To do this you will need to configure credentials
and information about your deployment in the values file. It is recommended to first configure a specific robot user for the account you’ll want to track your inventory in.
To install the helm chart, follow these steps:
- Configure your username, password, Anchore URL and cluster name in the values file.
# 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> # Note: reccommend using the inventory-agent role user: <user> password: <password>
- Run helm install in the cluster(s) you wish to track
$ helm repo add anchore https://charts.anchore.io $ helm install <release> -f <values.yaml> anchore/kai
Kai must be able to resolve the Anchore URL and requires API credentials. Review the kai logs if you are not able to see the inventory results in the UI.
Note: the Anchore API Password can be provided via a kubernetes secret, or injected into the environment of the
- For injecting the environment variable, see:
- For providing your own secret for the Anchore API Password, see:
kaicreates it’s own secret based on your values.yaml file for key
kai.anchore.password, but the
kai.existingSecretkey allows you to create your own secret and provide it in the values file.
As part of reporting images in your runtime environment, Anchore maintains an active record of that set of images based on when the Image has been last reported by
kai does not find an image that was previously in the inventory, it waits for a configurable TTL to expire before removing that image:
services: catalog: runtime_inventory: image_ttl_days: 120
By default a runtime inventory image’s TTL is set to 120 days. That means, that if
kai hasn’t seen your image in it’s configured contexts for more than 4 months, it will be removed from the active working inventory image set (no longer returned from
Image TTL can be disabled, if you only want
/v1/enterprise/inventories to return a recent set of active images, just set the value of
-1. If set to
-1, then the
/v1/enterprise/inventories API will always show the latest inventory reported by
In addition to running as agent kai can also be run by Anchore Enterpise in an embedded mode. In this mode
kai runs within the Anchore Enterprise, and needs a cluster configuration to access the Kubernetes API. This still requires cluster but allows for monitoring without the installation of additional components. See more details about setting up embedded mode.
CLI and API Inventory Collection
In situations where you may not be able to have consitent network connection
kai along with the inventory API can be used to collect and report inventory back to Anchore Enterprise. Inventory collection can also be used to collect other types of containers runtimes however non are officially supported at this time.
To quickly verify that you are tracking Kubernetes Inventory you can quickly access inventory results from the
anchorectl with the command
anchorectl inventory list. The UI for the Kubernetes allows operators to visually navigate vulnerability resultes, source where vulnerabilities come from and apply their default policy to their runtime. You’ll be able to subscribe to changes for your clusters, quickly asses vulnerabilities and more.
For more details about watching clusters, and reviewing policy results see the Using Kubernetes Inventory section.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.