The Kubernetes container-orchestration system provides a platform for automating deployments
and operations of application containers across clusters of hosts by defining resources as
manageable Objects. Some of these resources can be managed by other resources automatically
while others can be referenced through metadata fields within the object.
In time, some of these objects can go out of scope and will no longer be used causing them to go
into in a limbo state or become what we call orphaned resources. Thankfully, there is a garbage
collector (GC) in Kubernetes which helps cleaning up these objects but are all types of these
objects actually removed or will there still remain unhandled orphaned resources in the cluster?
The role of the Kubernetes GC is to delete objects that once had an owner, but no longer have
one. Some Kubernetes objects are owners of other objects. For example, a ReplicaSet object is
the owner of a set of Pods. The owned object are called dependents of the owner object.
In traditional programming languages, the basic principles of garbage collection are to find data
objects in a program that cannot be accessed in the future and to reclaim those resources used by
In Kubernetes, garbage collection works a bit differently. In conventional GC’s, the objects know
what other objects it owns however, in Kubernetes the dependents have an ownerReference field
that point to the owning object. The value of the ownerReference field is set automatically for
example, when creating a ReplicaSet Kubernetes sets the ownerReference field for each Pod in
The manifest shared below defines a ReplicaSet:
One of the pods in the ReplicaSet with the ownerReference field pointing to the ReplicaSet:
Once this mapping is done, when the parent is out of scope the resource that points to the parent
will also go out of scope. So in the previous example, if my-repset is deleted, the pod dependents
will become orphaned resources which will then be deleted by the garbage collector.
Other Kubernetes Resource Types
However, there are other resource types such as ConfigMaps or Secrets that have a different way
of mapping the relationship to other Kubernetes objects. In such cases when the dependent
objects to these resource types are deleted, the Kubernetes GC will not remove them resulting in
Take the following ConfigMap as an example:
Add an environment variable configuration from that ConfigMap in a Pod:
So now there is a ConfigMap with a Pod using it. Now if the Pod were to be removed, there would
be a ConfigMap that is not in use by any Kubernetes object which can now also be considered as
an orphaned resource. Since the Kubernetes GC relies on the ownerResource metadata to do its
work, these unused objects could remain in the cluster indefinitely. The same scenario is also
applicable for other resource types such as Secrets, ClusterRoles or even ClusterRoleBindings.
Unused Secrets that contain sensitive data or ClusterRoles that have escalated privileges could be
roaming in the cluster and would have the potential of being used unintentionally.
Finding The Orphaned Resources
How can such orphaned resources be located in the cluster? Is there really a way to pin down all of
these separated Kubernetes configuration objects that are no longer in use or considered as
orphaned resources? Enter the Alcide Advisor.
Alcide Kubernetes Advisor is a Kubernetes multi-cluster vulnerability scanner that covers rich Kubernetes and Istio security best practices and compliance checks such as Kubernetes vulnerability scanning, hunting misplaced secrets, or excessive secret access, workload hardening from Pod Security to network policies, Istio security configuration and best practices, Ingress controllers for security best practices, Kubernetes API server access privileges and Kubernetes operators security best practices.
Since the Alcide Advisor scans all Kubernetes resources, it can also be used to find unused
Kubernetes configuration objects and report all of the orphaned resources in the cluster. Want to
learn more? Check out the Alcide Advisor.