support for CRIO container runtime

[nyrahul]

Feature Request

Kubearmor currently supports docker, and containerd container runtimes for k8s.
There are several k8s engine (for e.g. OpenShift) that use CRIO.

Kubearmor connects to container-runtime to get the mount-namespace and other details (for e.g., container image details etc). These details are used subsequently in the telemetry/log enrichment. For e.g.,

1. to check if the process event is in context to the given container/namespace.
2. to check what is the container image id for the event that is generated

The aim here is to look into containerd implementation in kubearmor and map it to CRIO as well.

Tasks:

• design points
• validate policy enforcement with CRIO
• validate alerts/telemetry with CRIO
• testing with local k8s env with CRIO

[DelusionalOptimist]

@nyrahul @nam-jaehyun @daemon1024 I took a look into how support for other CRIs has been implemented and tried to draw parallels.
I think the client provided by CRIO doesn't give all the info that we need about the containers. For e.g. it doesn't provide the container spec (like containerd) through which we can get the apparmor profile. So, meanwhile I'm taking a looking into how we can get it, do you folks have any other suggestions/concerns?

Also, can one of you please assign this to me? Thanks.

[nam-jaehyun]

@DelusionalOptimist can you explain what values we cannot get from CRIO?

[DelusionalOptimist]

@nam-jaehyun I was comparing the container structs defined by containerd and cri-o and saw that containerd provides some more fields over cri-o which may affect how we implement this.
On a quick look I only realized the spec field which we use for getting the Apparmor profile associated with a conatiner.

[DelusionalOptimist]

I think the best (and only) option here would be to use the cri-api.
We can get basic data needed for a Container from cri-api's container, and its metadata, annotations and labels.
Apparmor profile from container status or container config (verified through crictl). And the approach thereafter remains similar.

Regarding usage of cri-api for working with other container runtimes - I think it will work out fine and I've tried them out with crictl but I propose we first support cri-o and later extend it for others.

If this sounds good, lmk so that I may start working on the implementation.

[nyrahul]

If cri-api can work, that will be the best thing to happen. But please have a look at this file to check what information we need from container runtime.

[DelusionalOptimist]

Yes @nyrahul, I had taken it into consideration as well.