Kubernetes projects
A Kubernetes project is a set of Docker images belonging to a namespace on a Kubernetes cluster, and seen as a single asset aggregating the vulnerabilities of the images it contains. Each image is listed as a technology of the project, which enables seeing which images are vulnerable without focusing on the contents of the images.
Creating a Kubernetes project
Kubernetes projects are a type of agentless connections. Their configuration data depend on the method used to access the cluster. It is always possible to connect to the cluster directly using the Kubernetes API, but in order to facilitate credentials management Cyberwatch integrates with Azure and AWS to fetch the Kubernetes configurations.
Kubernetes clusters
Accessing a Kubernetes cluster directly requires a set of stored credentials of type Kubernetes. The identifiers must have the following RBAC permissions:
- apiGroups: [""]
resources: ["namespaces/status", "pods/status"]
verbs: ["list", "get"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["list"]
See the Kubernetes documentation Using RBAC Authorization for more information.
The cluster will be selectable once the K8s project is created.
The Address field must contain the name of the namespace from which to list the images, for instance “my namespace”. In the case multiple clusters define the same namespace, the address may be prefixed by a cluster name separated by a slash, for example “my cluster/my namespace”. The name of the cluster in that case has no impact on the result of the scan.
Azure Kubernetes Service
To configure an AKS cluster, an API key for Azure is required. The process to add stored credentials for Azure is the same as that for Azure discoveries.
To identify an AKS cluster, 3 pieces of information are needed:
- the ID of the subscription to which it is attached,
- the name of its resource group, if any,
- the name of the cluster.
On the agentless connection creation form, select type Kubernetes project and then the Azure stored credential. The fields specific to Azure will be displayed.
The name of the cluster does not have its own field and must be written as the address, followed by a slash and then by the name of the namespace of the project, for example “my cluster/my namespace”.
Amazon Elastic Kubernetes Service
To configure an EKS cluster, an API key for AWS is needed. See Amazon Web Services discoveries for the set up process.
When creating the agentless connection of type project Kubernetes, the Address field must have the syntax “my cluster/my namespace” where “my cluster” is the name of the cluster on AWS, and where “my namespace” is the name of the namespace on the Kubernetes cluster.
EKS clusters also require specifying the geographical zone in the Region field. The Role field accepts an optional ARN for performing an AssumeRole operation, if necessary.
Scanning images
In order to have the vulnerabilities information, the images of the Kubernetes projects must be scanned independently as Docker images.
Kubernetes projects list their images by digest, which is used as key to find the scanned images. Scanned images must contain an IMAGE_DIGEST metadata, declared with META:IMAGE_DIGEST|sha256:…
in one of their analyses. The SHA-256 digest being the only criteria, the found image may be an air gap asset as well as a Docker image, may originate from a mirror registry or even have a different name. For more reliability it is preferable to register the images by digest rather than by tag.
To take into account the newly scanned Docker images, the Kubernetes project must be reanalyzed.
Manual registration
When images are missing from a Kubernetes project, they may be manually added from menu Assets management > Docker images in the lateral bar, specifying the digest of the image in the Tag field, for example sha256:50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c
.
The ease this process, missing Docker images can be registered by clicking the Add button at the right of the images in tab Technologies on the project’s details page.
Automatic registration
The easiest way to automatically scan the Docker images of a project is to register them automatically through a Docker discovery, and more specifically with a Kubernetes, AKS or EKS discovery whose perimeter is set to Running images.
If all the images are hosted on a Harbor registry, one may configure in the administration, among the external tools, a Harbor scanner. This approach has the merit of triggering the scan of the images as soon as they are pushed to the Harbor repository.
Discovering projects
Docker discoveries for Kubernetes, AKS and EKS support in their Perimeter the Namespaces option. This makes the discovery list the namespaces used on the pods rather than their images.
The discovered projects may be manually registered as assets from the list of discovered assets by using group action Scan with agentless connections, and then selecting type Kubernetes project.
Registration of new Kubernetes projects may be automated from the discovery’s edition form by enabling the automatic registration of discovered assets as agentless connections of type Kubernetes project.