A model of orchestration metadata for attack detection in containerized kubernetes environments

Abstract

The aim of the article is to formalize an event model of a containerized application extended with Kubernetes orchestration metadata, and to build a correspondence matrix, constructed through a formalized coding protocol, between this model and the ten risk categories of the Open Web Application Security Project Kubernetes Top 10. The relevance of the study stems from the fact that traditional intrusion detection systems built solely on system-call analysis do not account for Kubernetes orchestration context - namespace membership, role-based access control role, pod security profile, network policy, workload lifecycle phase, and cloud-identity binding - so identical system calls receive different risk assessments depending on context. The scientific novelty lies in the typed formal definition of the event structure with a stable entity identifier, a two-stage binding function, and explicit semantics for missing or stale metadata values, together with a correspondence matrix between six orchestration-metadata types and ten risk categories on a three-level necessity scale, built through an explicit, documented coding protocol. The subject of the study is the relationship between orchestration-metadata types and the contextual observability of containerized-environment risk categories at the process-event level - the ability to attribute a process event to a risk category's mechanism, not to detect the presence of the risk in the cluster. The research methods include formalization, structural analysis of the official OWASP Kubernetes Top 10 category descriptions, and a greedy algorithm for prioritizing metadata-type implementation with a full deterministic tie-breaking rule. The results show that the pod security profile and identity-mount metadata type is the most universal, being necessary for three risk categories, whereas three categories - overly exposed platform components, misconfigured and vulnerable cluster components, and inadequate logging and monitoring - are structurally not contextually observable by any of the examined metadata types at the process-event level, outlining the model's boundary of applicability. The greedy algorithm determined an implementation order that achieves full necessary-metadata coverage of the seven contextually observable risk categories, within the defined model, after just four steps. The study is analytical and formal rather than empirical in nature, which is stated as its limitation and direction for future work.