Using Kubernetes Labels for Analytics, Forensics and Diagnostics

Usually, when you hear us going on about labels here at Tigera, we are mentioning them as targets for selectors for network policies.  As a review, you might have a policy that says, “things labeled customerDB=server should allow traffic on 6443 from things labeled customerDB=client”  In this example, the labels identify a resource being produced or consumed.  Similar labels might also be used to identify state (such as being in stage dev, test, or prod, for example) or similar operational states or requirements. Labels might also make sense for operational purposes in Kubernetes, but I want to talk about using labels for diagnostics, auditing, and forensics.  In short, the use of labels in Kubernetes, from a security standpoint, can extend beyond the application as a policy target or anchor.

Calico’s labels capabilities

One of the capabilities of Tigera’s solution is to annotate flow logs with a substantial amount of metadata about the endpoints of the flows. Metadata includes: 1) the names of the endpoints which are immutable in Kubernetes, where IP addresses are ephemeral, 2) the namespaces involved, 3) the policy that allowed or denied the flow, and, most interestingly, for this discussion, 4) the labels that were attached to the sending and receiving workloads. This means that any labels that are attached to either the source or destination will show up in the flow logs.

So, how might that be useful?  For example, if pods were annotated with the git check-in hash(es) that were used to create them, they could contain the following information:

• Name of the developer that created them/li>
• Version information
• Project or group that it services or belongs to

All of the above information would be available as part of the flow logs in real time for forensic analysis.  Furthermore, if some form of machine learning is being used, then it would be possible to pick up patterns related to those tagged items (i.e., a specific developer or check-in).

Beyond the audit and visibility benefits, it also allows for other security operations.  For example, if a given container (identified by a hash) comes under suspicion or even a given developer, all the affected pods can be selected for and operated on. The use of labels is low-cost and can impart quite a bit of information to a pod or other artifact that can follow said artifact throughout its lifecycle.

In order to make such labels meaningful, it is best to have some form of schema or taxonomy for labels to ensure that there is a standard that is easily parsable and understood by all consumers of labels.  The more you use labels, the more important it is to make sure that they stay organized. So, the takeaway is that the use of labels for security in Kubernetes can be for more than a policy or other operational requirements.  It can also make auditing, forensics, and diagnostics easier and more automatable.

————————————————-

Free Online Training
Access Live and On-Demand Kubernetes Tutorials

Calico Enterprise – Free Trial
Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption