Support running on MacOS

[disconnect3d]

Currently the tool does not work on MacOS as there is no cgroupfs there, as used in https://github.com/cyberark/KubiScan/blob/ad55e1cfa59c56fcee4c355e0fd0cf51b3c67f7b/api/api_client.py#L22-L28

This can be fixed by checking if the running OS is MacOS and if so, not executing the is_running_in_container function.

[g3rzi]

Thank you for this update :) Can you please check now ?

I added check to see if cgroup exist.
I am not familiar with container without it, but if there are, we can add more checks to see if this is a container.

[disconnect3d]

Yes, the https://github.com/cyberark/KubiScan/commit/d4471d12cbb3706b2bef60c2e764dc985a7e9491 works. I think a "cleaner solution" would be to explicitly check for the operating system and don't call the running_in_docker_container in case when it is other than Linux? This could be done e.g. via:

import platform

# interestingly its docstring says:
#     Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'.
# but it returns 'Darwin' for MacOS
os = platform.system().lower()

if os == 'linux' and running_in_docker_container():
    # ...

But I am completely fine with the current solution too.

I am not familiar with container without it, but if there are, we can add more checks to see if this is a container.

There are no native containers on MacOS and the Docker for Mac just uses a linux VM under the hood (see e.g. https://docs.docker.com/docker-for-mac/install/). Also, I don't think people run containers with e.g. procfs mounted in a different path or without cgroups. Though, we may see containers being based on cgroups v2 (which maybe produces different output of /proc/self/cgroup? not sure here).

[disconnect3d]

Closing this since it works, thanks :).