We have a small script (caps.py
) that gets the capabilities information directly from CRI-O.
A container image is used, it has the caps.py python script and the crictl
and kubectl
binaries.
What we want is connect to the CRI-O runtime from every OpenShift node in order to get information around the containers that are running on the node, we need to do that for every node in the cluster.
A DaemonSet is used to run our container image on every node, we need to mount the CRI-O sock file inside our container as well as grant access to the host network. Once we have the CRI-O sock file and the host network enabled, we can query the CRI-O runtime of the node from our pod.
-
Create the required objects:
NOTE: Below command must be run as a cluster-admin user.
oc create -f deploy.yaml
-
A pod will be running on every node inside the
getcaps
namespace:oc -n getcaps get pods
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES getcaps-425hh 1/1 Running 0 27m 192.168.123.8 openshift-worker-0 <none> <none> getcaps-jg7rg 1/1 Running 0 27m 192.168.123.6 openshift-master-1 <none> <none> getcaps-l6wzx 1/1 Running 0 27m 192.168.123.5 openshift-master-0 <none> <none> getcaps-szb58 1/1 Running 0 27m 192.168.123.10 openshift-worker-2 <none> <none> getcaps-vmtc5 1/1 Running 0 27m 192.168.123.7 openshift-master-2 <none> <none> getcaps-ztr92 1/1 Running 0 27m 192.168.123.9 openshift-worker-1 <none> <none>
-
You can get the logs of the pods to get information related to capabilities assigned to containers running on the node:
oc -n getcaps logs getcaps-ztr92
NOTE: Namespaces appended to the output can be specified by using arguments on the DaemonSet, check the comments in the deploy.yaml file. An extended output is also available, this output will give you information about container uid/gid, image being used, privileged bit, entrypoint and scc used by the pod. Check the comment in the deploy.yaml file to get the extended output enabled. The tool can simulate clearing the permitted and effective capability sets when the container does run with a nonroot UID, in order to enable this output check the comment in the deploy.yaml file.
caps: - namespace: getcaps pods: - name: getcaps-zxwr8 containers: - name: getcaps capabilities: - inherited_set: - CAP_CHOWN - CAP_DAC_OVERRIDE - CAP_FSETID - CAP_FOWNER - CAP_SETGID - CAP_SETUID - CAP_SETPCAP - CAP_NET_BIND_SERVICE - CAP_KILL - permitted_set: - CAP_CHOWN - CAP_DAC_OVERRIDE - CAP_FSETID - CAP_FOWNER - CAP_SETGID - CAP_SETUID - CAP_SETPCAP - CAP_NET_BIND_SERVICE - CAP_KILL - effective_set: - CAP_CHOWN - CAP_DAC_OVERRIDE - CAP_FSETID - CAP_FOWNER - CAP_SETGID - CAP_SETUID - CAP_SETPCAP - CAP_NET_BIND_SERVICE - CAP_KILL - bounding_set: - CAP_CHOWN - CAP_DAC_OVERRIDE - CAP_FSETID - CAP_FOWNER - CAP_SETGID - CAP_SETUID - CAP_SETPCAP - CAP_NET_BIND_SERVICE - CAP_KILL - namespace: openshift-kube-apiserver pods: - name: kube-apiserver-openshift-master-2 containers: - name: kube-apiserver-check-endpoints capabilities: <OMITTED_OUTPUT>