Scanning your Kubernetes Cluster
Dear JDisc friends,
with release build 5198 for our network scanner JDisc Discovery, we have completely changed the way we scan Kubernetes clusters. Up until now, users were able to define default access tokens for Kubernetes clusters, which were tried against the cluster whenever we found one. This approach does not really make a lot of sense because no two clusters will have the same token.
Another difficulty could be that we needed to have the cluster node offering the API discoverable. That means it should be at least pingable. However, in many cases, installations in the cloud do not even reply to ping. Only the port offering the API is open for requests.
The changes we made are similar to how we scan cloud environments. PaaS (Platform as a Service) is a new area within the discovery configuration. The first entry is Kubernetes. Later, we will add CloudFoundry.
There are two ways to provide access to the Kubernetes cluster:
- service account token
- a kube.conf file
Adding Kubernetes Access using a Service Account Token
In Kubernetes, administrators can create service accounts and create a long-living access token for them. Click the Add button to add access to new Kubernetes clusters.
Provide a descriptive name and comment, choose the access credential type Service account token, enter the cluster IP or hostname, port, and finally, the service account token.
Adding Kubernetes Access using a Kube.conf File
The second option for granting access to a Kubernetes cluster is a kube.conf file. This file includes all information (address, credentials, certificates) needed to access the Kubernetes cluster.
Testing Access
Click the Test button to check the credentials for your Kubernetes cluster!
Required Permissions
JDisc Discovery reads the following artifacts from the Kubernetes cluster:
- Namespaces
- Services
- Nodes
- Pods
- Container
- Replicasets
- Daemonsets
- Container images
Therefore, we need at least permissions with the verbs
- get
- list
If you would like to get the list of applications installed in a container running as part of a POD, you also need the following permission:
- pod/exec
Getting Applications within a Container
We have also extended our code to retrieve the list of applications running within a container. Note that we need the POD/EXEC permissions to execute commands within a container that is part of a POD.
However, we are currently facing a challenge. We have yet to find a way to provide these permissions to a Service Account (and its token). It’s important to note that service accounts are per namespace and, as a result, do not have permissions to other namespaces and their pods.
The only way to get POD/EXEC permissions for all PODs and all namespaces is to use a kube.conf file with an ordinary user and its proper cluster role assignment with the required permissions.
Creating a Job to scan Kubernetes Clusters
Finally, we can create a discovery job that is responsible for running the PaaS discovery for all configured Kubernetes clusters.
Create a discovery job using the context menu within the left discovery job list. Please provide a name and description and select it after clicking Ok. Don’t assign any group to the job; select Synchronize PaaS as the only option within the Settings tab. When the job starts, it will only connect to the configured PaaS entries and scan the environments.
We hope that our new approach makes you life a lot easier and clearer and as usual, we are looking forward getting feedback and your ideas.
