[BUG] Update process search module to search using proc on the host fs

[denverwilliams]

Describe the bug Currently the process search module looks at running processes within each container to determine the process name & type. This is only possible when ls is available. It's a common security practice to remove ls and any other binaries from a container image, in such cases a search in not possible.

This can be solved by instead looking searching on the host /proc for the processes where ls is available to us.

Steps:

Get Workload Resource name and container id:

☺ ➔  kubectl  get pods -o custom-columns=Name:metadata.name,DockerID:.status.containerStatuses[*].containerID                                                                                                     │·Name                                         DockerID                                                                                                                                                             │·
cri-tools-sqbhh                              containerd://1b2f0a67fe66b3a34d91b0458df09051a1a43fa3268121b0e1defb0fafa2f56a                                                                                        │·
metris-kube-state-metrics-66cb76f6d4-8j8jc   containerd://d74bfff814e9fe6e7399fa1487330b4c71d2e67c3fce9daa4c270d2823a1eb90

Get PID:

crictl inspect d74bfff814e9f

  "info": {
    "sandboxID": "0f094823a40b54f71549b8e12475d24c88fe2b8fbe3abd9ecbee87089944a689",
    "pid": 536364,
    "removing": false,
    "snapshotKey": "d74bfff814e9fe6e7399fa1487330b4c71d2e67c3fce9daa4c270d2823a1eb90",
    "snapshotter": "overlayfs",
    "runtimeType": "io.containerd.runc.v2",
    "runtimeOptions": {
      "systemd_cgroup": true
    },

Get CMD

root@vulk01-control-plane:/# cat /proc/536364/cmdline 
/kube-state-metrics--port=8080--telemetry-port=8081--port=8080--resources=certificatesigningrequests,configmaps,cronjobs,daemonsets,deployments,endpoints,horizontalpodautoscalers,ingresses,jobs,limitranges,mutatingwebhookconfigurations,namespaces,networkpolicies,nodes,persistentvolumeclaims,persistentvolumes,poddisruptionbudgets,pods,replicasets,replicationcontrollers,resourcequotas,secrets,services,statefulsets,storageclasses,validatingwebhookconfigurations,volumeattachments--telemetry-port=8081root@vulk01-control-plane:/#

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• OS [e.g. Linux, iOS, Windows, Android]
• Distro [e.g. Ubuntu]
• Version [e.g. 18.04]
• Architecture [e.g. x86, arm]
• Browser [e.g. chrome, safari]

How will this be tested? aka Acceptance Criteria (optional)

(optional: unnecessary for things like spelling errors and such)

Once this issue is address how will the fix be verified?

Additional context Add any other context about the problem here.

---

NOTE: you can enable higher logging level output via the command line or env var. to help with debugging

# cmd line
./cnf-testsuite -l debug test

# make sure to use -- if running from source
crystal src/cnf-testsuite.cr -- -l debug test

# env var
LOGLEVEL=DEBUG ./cnf-testsuite test

Also setting the verbose option for many tasks will add extra output to help with debugging

crystal src/cnf-testsuite.cr test_name verbose

Check usage documentation for more info about invoking commands and logging

[agentpoyo]

AC and Review ill be done in https://github.com/cncf/cnf-testsuite/issues/1581

[lixuna]

@denverwilliams @wavell @agentpoyo what is the level of effort in points for this issue (0,1,2,3,5,8,13)?

[lixuna]

@denverwilliams @wavell @agentpoyo what is the level of effort in points for this issue (0,1,2,3,5,8,13)?

[agentpoyo]

5pts