The Docker discoveries let you list the set of Docker images available from a registry, or pulled into an existing Docker deployment. The discovered Docker images can then be added to Cyberwatch with a grouped action for scanning.
If you have an Amazon Elastic Kubernetes Service cluster, you can scan it with Cyberwatch to list all the images deployed on it.
Once the credential set is ready, you can create the AWS EKS discovery by going to Discoveries, then clicking Add and AWS EKS in the Docker images category. You can find the information relatives to the discovery creation here.
If you have an Azure Kubernetes Server (AKS) cluster, you can scan it with Cyberwatch to list all the images deployed on it.
AKS discoveries require a Microsoft Azure credential set, that you can create from menu Stored credentials, and are documented here. The credential should have read access on the Managed Clusters routes and the scanned clusters.
Once the credential set is ready, you can create the AKS discovery by going to Discoveries, then clicking Add and Azure Kubernetes Server (AKS) in the Docker images category. You can find the information relatives to the discovery creation here.
If you have a private Docker registry, and a service account able to enumerate its images catalog, you may create an asset discovery in Cyberwatch to list all the available Docker images.
To use the Docker images discovery, you need to add your Docker registry using the Stored credentials menu. You will then be able to add a Docker registry discovery from menu Discoveries with clicking Add, then Docker registry in the Docker images category.
If the registry is properly configured, the discovery will list all the found Docker images along with their tags.
A Harbor registry may be scanned like any other Docker registry but it requires Harbor system administrator credentials. Harbor registry discovery instead uses Harbor’s REST API to discover accessible Docker images and can be used with a guest account. However, Harbor system administrator credentials must be used to be able to access to all the projects present on the registry.
To use the Harbor registry discovery, you need to add your Harbor registry as Docker Registry from the Stored Credentials menu. You will then be able to add a Harbor registry discovery from the Discoveries menu with clicking Add, then Harbor registry in the Docker images category. If the registry is properly configured, the discovery will list all the found Docker images.
On a Harbor registry, the Docker registry discovery will list all artifacts with a tag, and not just the images while the Harbor registry discovery allows to list all the images whether they have a tag or not.
Docker Swarm discoveries let you list the images available locally on a Docker execution engine. They apply to Docker Swarm deployments but are not limited to them: any Docker daemon will be compatible.
Only tagged Docker images will be listed, which excludes intermediate images, or images pulled with an explicit ID.
A Docker engine credential set is required for this type of discovery. To create one, please refer to the documentation on Docker images.
One the credential set is ready, you can create the Docker Swarm discovery by going to Discoveries, then clicking Add and Docker Swarm in the Docker images category.
If you have a Kubernetes cluster, you can scan it with Cyberwatch to list all the images deployed on it.
Kubernetes discoveries require a credential set, that you can create from menu Stored credentials. The essential pieces of information you need are (1) the entry point to the Kubernetes API, for example
https://cluster-ip:6443, and (2) the authentication token, which is typically a JWT. You can easily extract these from the YAML configuration of a service account by looking for keys
One the credential set is ready, you can create the Kubernetes discovery by going to Discoveries, then clicking Add and Kubernetes in the Docker images category.
GitLab integrates a Docker registry called GitLab Container Registry for storing Docker images associated to GitLab projects. It may be scanned like regular Docker registry but requires super-administrator credentials. GitLab Container Registry instead uses GitLab’s REST API to discover accessible Docker images, and can be used even with a regular user.
This discovery requires a GitLab access token that you can create from the user settings of your account on GitLab. The access token must have read_api permissions. Once created, you need to add it to Cyberwatch as Stored credentials.
Finally, you can create the discovery from menu Discoveries by choosing type GitLab Container Registry and then selecting your credential set.
Cyberwatch scans on Linux locate and analyze the images of Docker containers currently running on a Linux machine.
This discovery retrieves all Docker images present on all Linux machines within the Forwarded scope.
By default, the Forwarded scope encompasses all Linux assets, but it is possible to narrow it down by selecting one or more groups in the Forwarded scope field of the form.
From the discovery assets list, you may see and filter the Docker images without any associated assets. To add them to Cyberwatch, pick the images you wish to scan and click Bulk actions > Scan as Docker images.
To scan an images, you will need a Docker engine. If you have not configured one yet, please refer to Add a Docker image.
Newly discovered Docker images can be automatically added to Cyberwatch as they are discovered. To enable this feature, you need to go to the discovery edition form and specify a Docker engine.
The registry is automatically selected based on the name of the discovered image. For instance, the image
example.com/library/hello would automatically use the registry
example.com, provided it has been added as a stored credential. New registries are automatically added as stored credentials, and you can manually edit them if they require authentication. You may in certain contexts select a preferred registry, but it will only be selected when the registry in the name of the discovered image matches the entry point of the registry.