Retrieving metadata from the Kubernetes API
Digger utilizes the Kubernetes API to gather metadata on these entities:
services. This process employs the method depicted as Efficient detection of changes in the official K8s documentation.
ServiceAccount is created. This
ServiceAccount is given cluster-wide permissions (
watch on several
apiGroups. Digger gets these access rights by using this
Here's how the communication between Digger and the Kubernetes API is structured:
In more detail:
During the initiation phase of the Agent, Digger conducts three
listcalls to collect initial data on collections of
Subsequently, Digger initiates three
watchcalls, essentially subscribing to notifications about configuration modifications in entities of these three types.
In scenarios where the Kubernetes API is unavailable due to any reason, Digger attempts to re-subscribe, with the waiting duration between attempts incrementing exponentially.
For the subscription process, Digger employs the
resourceVersionso that Kubernetes will only transmit new events to it.
Upon receiving a new entity in the notifications from Kubernetes, Digger processes the metadata, such as the name, namespace, labels, and annotations, storing these in the cache.
Digger also identifies the higher-level Kubernetes construct that created this entity, in other words, the workload resource (such as
Deployment, among others) that serves as the actual owner of this entity. This gives a broader context, for instance, to the pod name (which could be quite cryptic in isolation) of the discovered asset.