Четвертая часть из цикла [1,2,3] про sensor-based решения по безопасности для Kubernetes.

Что это за контейнеры, за которыми идет наблюдение разные решения могут видеть на разном уровне детализации. Тут нужно вспомнить как работает Kubernetes с Container Runtime через CRI. Вся цепочка создания Pod сокращенно выглядит так: создаётся ресурс Pod, далее Container Runtime создает контейнер и происходит обновление статуса ресурса через добавление информации о контейнере, который работает в данном Pod'е. Kubernetes только уже после фактического запуска контейнера связывает информацию с ресурсом Pod.

В связи с этой не очень простой схемой разные решения к контейнеру присоединяют (enrichment стадия) разное количество информации. Самый полный комплект выглядит таким образом:
- Image : k8s.gcr.io/etcd
- Digest : sha256:303ce5db0e90dab1c5728ec70d21091201a23cdf8aeca70ab54943bbaaf0833f
- Tags : k8s.gcr.io/etcd:3.4.3-0
- Container ID : eaadea8d867e2833b1fee449a993ec96c2708bbec37e9349369a6541f796d9ae
- Container Name : etcd
- Cluster : PROD
- Node : flex-f94c4afe-1
- Namespace : kube-system
- Pod : etcd-flex-f94c4afe-1
- Kubernetes Resource : StaticPod:etcd
- UID : 816f47b8-02bd-456d-8b1e-3b1a3f1fa318

Чем больше решение присоединяет информации к контейнеру или событию в нем, тем проще расследовать сбои и инциденты.