Integration with third-party resources

To identify security issues and ensure protection of containerized applications, Kaspersky Container Security can integrate with the following third-party resources:

• External image registries. The solution allows scanning container and IaC images hosted on repository management and storage platforms, including as part of the CI/CD process, for vulnerabilities, malware, misconfigurations, and the presence of sensitive data.
• Image signature validators. Kaspersky Container Security can validate digital signatures of images using an external signature application.
• Output. When implementing response policies, the solution can notify users about security events by sending messages via email or Telegram.
• External LDAP directory services. When defining user roles and scopes, the solution allows configuring user accounts based on data from an external directory service and map user roles to user groups from Active Directory.
• SIEM systems. Kaspersky Container Security allows connection to security information and event management systems to notify about events for analysis and further respond to potential threats.
• HashiCorp Vault external storage. The solution allows to securely store and use passwords, tokens and secrets by means of HashiCorp Vault.

Setting up integration with external image registries

Kaspersky Container Security can scan images from the following external image registries:

• Harbor
• GitLab Registry
• JFrog Artifactory
• Sonatype Nexus Repository OSS
• Yandex Registry
• Docker Hub
• Docker Registry

  Integration with Docker Registry requires support of the Docker Registry V2 API on the external registry server side.

• Red Hat Quay
• Amazon Elastic Container Registry

You need to configure the integration of the solution with external registries so that the solution can scan images from external registries. Images from registries integrated with Kaspersky Container Security can be scanned automatically or manually, depending on the configured image pulling and scanning settings for each registry.

Minimum sufficient rights for integration with registries

To integrate with external image registries, a Kaspersky Container Security account must have a certain set of rights, which differs depending on the registry type. The list of the minimum account rights required for integration is given below for each registry type.

GitLab

To integrate the solution with a GitLab user's registry, you should define the parameter values as follows:

• User role in the project or group: Reporter.
• Level of access to the project: Reporter.
• Rights assigned to the user token: read_api, read_registry.

JFrog Artifactory

To integrate the solution with a JFrog user's registry, you should define the parameter values as follows:

• User role in the project or group: Manage Reports.
• Project access: Can Update Profile.
• User rights: the right to read any repository (ANY repository).

Harbor

To integrate the solution with a Harbor user's registry, you should define the parameter values as follows:

• Member type: user. To do this, specify User in the Member Type column of the table in the Projects → Members section.
• User role in the project or group: user with limited rights. To do this, you must specify Guest in the Role column of the table in the Projects → Members section.
• User rights: user without administrator rights. To do this, you must select No in the Administrator column of the table in the Users section.

Nexus

To integrate the solution with a Nexus user's registry, you should define the parameter values as follows:

• User role in the project or group: user.
• Rights assigned to the user role in the project or group: nx-apikey-all, nx-repository-view-docker-*-browse, nx-repository-view-docker-*-read.

Docker Hub

The solution integrates with a Docker Hub user's registry after authorization using the user name and password.

This Docker Hub registry integration option only applies to a personal namespace.

RedHat Quay

To integrate the solution with a RedHat Quay user's registry, the following rights and permissions are required:

• User permissions for correct operation of the Test Connection functionality: user with the Administer Organization permissions.
• View all visible repositories permissions.
• Read/Write to any accessible repositories permissions.

Yandex

To integrate the solution with a Yandex user's registry, you should define the parameter values as follows:

• User role in the project or group: container-registry.viewer.
• Permissions given to a user role in a project or group: view container registries.

Amazon Elastic Container Registry

To integrate the solution with an Amazon Elastic Container Registry user's registry, you should define the parameter values as follows:

• AWS policy for accessing a project or group: AmazonEC2ContainerRegistryReadOnly.
• Permissions given to a user role in a project or group: view and read.

Working with public registries without authorization

Kaspersky Container Security 2.0 does not work with public registries without authorization. For example, you cannot use the solution to scan images when Docker Hub is accessed anonymously.

If you do not authorize in public registries, you can use such image registries in a cluster, add them to Kaspersky Container Security and manually assign them to a specific scope. If the scope includes only one or several public registries in which you are not authorized, and you try to add an image in the Resources → Registries section, the solution displays an error indicating that it is impossible to add images because the solution has no registry integration.

Adding integrations with external image registries

Integrated registries support only local image repositories that directly contain the images. In version 2.0, Kaspersky Container Security does not support working with remote or virtual repositories.

To add an integration with an external registry:

1. In the Administration → Integrations → Image registries section, click the Add registry button.

   The integration settings window opens.

2. On the Registry details tab, specify the settings for connection to the registry:
   1. Enter the name of the registry.
   2. If required, enter a description of the registry.
   3. Select the registry type from the drop-down list. Kaspersky Container Security supports the following types of registries:
      • Harbor (integration using the Harbor V2 API).
      • GitLab Registry (integration using the GitLab Container Registry API).
      • JFrog Artifactory (integration using the JFrog API).
      • Sonatype Nexus Repository OSS (integration using the Nexus API).
      • Yandex Registry (integration using the Yandex Container Registry API).
      • Docker Hub (integration using the Docker Hub API).
      • Docker Registry (integration using the Docker Registry V2 API).
      • Red Hat Quay (integration using the Red Hat Quay API).
      • Amazon Elastic Container Registry (integration using the Amazon Elastic Container Registry API).

      The Docker Registry can be accessed using the Docker Registry V2 API if you configure integration with the Sonatype Nexus Repository OSS, Harbor, JFrog Artifactory (using a port or a subdomain), or Yandex Registry. Integrations with GitLab Registry, Docker Hub, and JFrog Artifactory (via Repository Path) are not supported.

   4. If you set up a JFrog Artifactory registry integration, select one of the following methods in the Repository Path method drop-down list to access Docker:
      • Repository path.
      • Subdomain.
      • Port.
   5. If you configure integration with the Sonatype Nexus Repository OSS registry, select the pull mode: Tagged images or All images. If All images mode is selected, the solution pulls all registry images regardless whether they have or lack tags. Untagged images are displayed with the build hash.
   6. If you configure an integration with a registry such as JFrog Artifactory, Harbor, GitLab Registry, Sonatype Nexus Repository OSS, Docker Registry, or Red Hat Quay, enter the full URL of the registry that directly points to the container registry. We recommend that you use HTTPS connection (HTTP connection is also supported).

      If you use HTTP or HTTPS with a self-signed or invalid certificate, you should check the insecure-registry box for the Docker engine on the nodes where the server and scanner are installed.

   7. If you configure an integration with a registry such as JFrog Artifactory, Harbor, GitLab Registry, and Sonatype Nexus Repository OSS, or Red Hat Quay, enter the full URL that points to the registry API.
   8. Select an authentication method and specify the necessary data for it as follows:
      • If you configure an integration with such registry as GitLab Registry, select authentication using an account or an access token.
      • If you configure an integration with such a registry as Yandex Registry, select authentication using an API key (Yandex OAuth token) or using a user name and token. Specify oauth for the user name when using the Yandex OAuth token, or iam when using the Yandex IAM token.
      • For such registries as Sonatype Nexus Repository OSS and Docker Hub, authentication is performed only with an account.
      • For such a registry as Harbor, authentication is only permitted with an account of a user or a robot.
      • For such a registry as Docker Registry, authentication is only conducted using a user name and password, which are provided by the Docker V2 API.
      • For Red Hat Quay registries, organization name and access token is the only authentication method. Specify these parameters in the Organization name and OAuth token fields.
      • For Amazon Elastic Container Registries, you can authenticate by specifying the region, Access key ID, and Secret access key .

        In the Region field, you must specify one of the Amazon Web Services regions (for example, us-west-2 or us-east-2).

        For Access key ID and Access key settings, you must specify values that you can get using the AWS management console.

3. Go to the Repository caching tab and use the Disabled/Enabled toggle switch to enable repository caching if necessary. If caching is disabled, repositories and images in the Registry section are displayed only if the Search field is used. If caching is enabled, the solution displays the list of available repositories and images. By default, repository caching is disabled.

   Enabling repository caching may impact the performance of Kaspersky Container Security.

4. Go to the Image scan details tab and specify the following image scan settings:
   • Scan timeout in minutes for images from this registry. The default scan timeout is 60 minutes.

     If image scanning lasts longer than the specified time, the scanning stops and the image is returned to the scanning queue. The solution will requeue the image up to 3 times. This means that the time required to scan an image from the registry may be tripled.

     Image pull and scan settings for the registry. By default, the Manual option is selected in Pull and scan images: images are not automatically pulled from the registry, but the user can manually add images to the list of images for scanning. New images are automatically queued for scanning.

     If you want images to be pulled from the registry and queued for scanning automatically, select Automatic in Pull and scan images and configure the settings for image pulling and scanning. The following options are available:

     • Scan interval (days) is the interval in days of image pulling from the registry for scanning. The default setting is 1 day.
     • Scan time (GMT) is the time when the images in the registry were scanned.
     • If necessary, select the check box to re-scan previously pulled images whenever new images are scanned.
     • If necessary, under Advanced settings, select the Name / tag criteria check box to use image name or tag patterns to specify which images you want to be pulled and scanned. If you select the check box, Kaspersky Container Security will only pull those images that match the specified patterns for scanning.

       You can use the following patterns:

       • by image name and tag – <name><:tag>
       • by image name only – <name>
       • by image tag only – <:tag>

       For example:

       • for the alpine pattern, all images with the name "alpine" are pulled, regardless of the tag;
       • for the 4 pattern, all images with tag 4 are pulled, regardless of the image name;
       • for the alpine:4 pattern, all images with the name "alpine" and tag 4 are pulled.

       When generating patterns, you can use the * character, which replaces any number of characters.

       You can add one or more patterns.

     • Select one of the additional conditions for pulling images:
       • If no additional conditions are required, select No additional conditions.
       • If you want to pull only images created within a specific time frame, select this option and in the fields to the right, specify the duration of the period and the unit of measure. By default, the period is 60 days long.
       • If you want to pull only images with the latest tags, counting from the date when the image was created, select this option and in the field to the right, specify how many of the latest tags from each repository you want to be taken into account.
     • If necessary, under Exceptions, select or clear check boxes to specify exceptions for image pulling:
       • Never pull images with the name/tag pattern - using image name/tag patterns you can specify, which images are excluded from pulling and scanning.
       • Always pull images with the name/tag pattern—using image name/tag patterns you can specify, which images are always pulled and scanned, regardless of other conditions set above.
5. Click Test connection to see if a connection with the registry can be established.
6. Click the Save button in the top of the window to save the registry integration settings.

Example of Red Hat Quay registry integration settings

Viewing information about integrations with registries

You can view a table with the list of all registries integrated with Kaspersky Container Security in the Administration → Integrations → Image registries section.

The table displays the following information about integrated registries:

• Name of the image registry integration
• Description, if one was specified when creating the integration with the image registry
• The type of the connected registry.
• Registry URL
• Status of the last connection with the image registry: Success or Error. If Error is displayed, the solution also displays a brief description of the connection error.

In the table, you can:

• Add new registry integrations. Click Add registry above the table to open the integration settings window.
• View and modify registry integration settings, including image pull and scan settings. You can open the editing window by clicking the registry name link.

  In this window, you can also click Test connection to see if a connection with the registry can be established.

• Delete integrations with registries.

Deleting integration with external registry

To delete an integration with an external registry:

1. In the Administration → Integrations → Image registries section, select the integration you want to delete by selecting the check box in the row with the registry name. You can select one or more integrations.
2. Click Delete above the table.

   The Delete button becomes enabled after you select one or more integrations.

3. In the window that opens, confirm the deletion.

Kaspersky Container Security does not scan images from a registry it is no longer integrated with.

Harbor integration

Integration of Kaspersky Container Security with the external Harbor registry can be performed in two ways:

• In the same way as integration with other external registries
• Upon the request of the external Harbor registry

Harbor views the solution as an additional external scanner to scan objects for vulnerabilities. Integration with Kaspersky Container Security is configured using the Harbor scanner plugin. The solution names this automatically created image registry as Harbor External Integration and marks the repository in which it is located with the Harbor icon ().

This integration remains the only automatically created integration with Harbor, and the name assigned to the image registry cannot be changed.

To start the Harbor scan process, you need to know the endpoint of the Kaspersky Container Security API.

To create an integration by Harbor request it is required to have rights to view and configure scanning in CI/CD. If these rights are absent, Harbor will not be able to connect the solution as a scanner and scan objects as part of the CI/CD process.

Creating an integration upon Harbor request

To create registry integration by Harbor request, you must have a Harbor account with administrator rights, as well as rights to view and configure scanning in CI/CD in Kaspersky Container Security. If these rights are not available, Harbor will not be able to connect the solution as a scanner.

To create a Harbor integration upon Harbor request:

1. From the main menu in the left pane of the Harbor web interface, select Administration → Interrogation Services.
2. Click the New Scanner button.
3. Enter the following information:
   • The unique name of the solution integration to be displayed in the Harbor interface.
   • If necessary, a description of the external scanner that is being added.
   • The address of the Kaspersky Container Security API endpoint displayed by Harbor.
4. In the Authorization drop-down list, select APIKey as the authorization method when connecting the registry to the solution.
5. In the APIKey field, enter the value of the API token.

   If the API token changes, you must specify its new value before starting the Harbor scan. If a new API token is not added to the external scanner settings in Harbor, the scan fails.

6. Select the Skip certificate verification check box to skip certificate verification.
7. If necessary, click Test Connection to verify that Harbor can connect to the solution.
8. Click Add to create the integration.

In the list of available scanners under Administration → Interrogation Services → Scanners, Harbor shows the name assigned to the solution in the Harbor.

The new scanner is used for scanning objects if it is specified as the default scanner in Harbor or assigned to the project. Both options require additional configuration in Harbor.

After scanning is started, an integration with the solution upon Harbor request is created in the external registry. Kaspersky Container Security displays the created Harbor External Integration registry in the list of image registries in the Administration → Integrations → Image registries section. The repository containing images from the external registry is marked with the Harbor icon (). Harbor External Integration is updated after starting and running another scan in the external registry.

You cannot add an image to an automatically created registry of images from Harbor by using the Add images button in the management console.

Harbor External Integration scans can be manually initiated or automatically started from the external registry. You cannot start scanning or rescanning images from the Harbor automatically created image registry in Kaspersky Container Security.

The Harbor External Integration registry (as well as the registry created as part of the standard integration with Harbor) is scanned in line with the applicable scanner policy.

At the end of the scan, the solution generates a report on vulnerabilities found during scanning of selected objects and sends it to Harbor. If sending a report takes more than five seconds (for example, because of the quality of the network connection), an error in receiving scan results is displayed in the external registry interface.

Viewing and editing the Harbor External Integration settings

The Harbor External Integration image registry is displayed in the list of registries integrated with Kaspersky Container Security in the Administration → Integrations → Image registries section.

To change the Harbor External Integration settings:

1. Select the Harbor External Integration registry in the list of image registries in the Administration → Integrations → Image registries section.
2. Specify the values of the following configurable settings:
   • Description on the Registry details tab.
   • Scan timeout on the Image scan details tab.

   You cannot change other Harbor External Integration registry details.

3. Click Save.

Rescanning

After receiving the scan results, objects from the Harbor External Integration registry cannot be sent for rescanning from Kaspersky Container Security. Rescanning can only be initiated from Harbor.

If you create an integration with Harbor from Kaspersky Container Security and the created image registry is similar to Harbor External Integration, the following rules are applied to rescanning:

• Scanning objects in the registry created in the solution does not trigger a rescan in Harbor External Integration.
• Scanning objects in Harbor External Integration does not trigger a rescan in the registry created in the solution.

Integration with CI/CD

Kaspersky Container Security lets you scan images of containers and IaC residing in code repository management systems in the

At the project build stage in the repository management system, you can run the Kaspersky Container Security scanner to check the objects in the repository for compliance with the enabled security policies. The scanner is started from a registry using an agent, such as GitLab Runner in GitLab. Data on the scan job and sending scan results are forwarded through the application programming interface (API).

When running an object scan during the project build stage, you must make sure that the Fail CI/CD step is not selected in the settings of the applied assurance policy. If this setting is activated, the solution will notify you of an error during the scan.

The scan results are displayed in the list of images in the Inventory → CI/CD → Scanning in CI/CD section.

For each of the objects in the table, Kaspersky Container Security displays the following:

• Date and time of the last scan.
• Name.
• Risk rating.
• Summary scan results with an indication of the identified objects related to vulnerabilities, malware, sensitive data and misconfigurations.
• Artifact type.
• The number and pipeline of the build in which the image was scanned.

In the Resources → CI/CD → Scanning in CI/CD section, you can also generate a report for images that are scanned within the CI/CD process.

Reports are generated only for objects with the Image artifact type. In this section, a report cannot be generated for other types of artifacts.

Artifact scanning in CI/CD processes

Kaspersky Container Security allows you to scan images that are used in CI/CD. To scan images from CI/CD, you should configure the integration of Kaspersky Container Security with CI/CD processes.

Data from listening to and intercepting network traffic must be securely transferred between the CI/CD environment and the solution.

To scan images or repositories (in order to scan configuration files) used in the CI/CD process, add a stage to the CI/CD pipeline that runs the Kaspersky Container Security scanner.

To scan images from CI/CD, in the configuration file used to integrate the repository, specify the API_BASE_URL (web-address of the Kaspersky Container Security API server) and API_TOKEN (token to access API of the Kaspersky Container Security) environment variables for the scanner. You must also specify API_CA_CERT (certificate for verifying host server of the API solution) or SKIP_API_SERVER_VALIDATION = true to skip this scan.

The scanning results are forwarded to the server and displayed in the Management Console in the Resources → CI/CD section. The provided table lists the images that were scanned, shows the results of the risk assessment, and indicates the detected vulnerabilities.

You can click the image name link to open a page with detailed information about image scanning results. This page is similar to the page showing the results of registry images scanning.

Kaspersky Container Security also displays the type of artifact for each object. Two main artifacts are used:

• File system is repository containing configuration files.
• Container image is template used for runtime implementation of the container.

For each scan object, you can specify the build number (BUILD_NUMBER) and the build

For CI/CD images, rescanning is not provided.

Kaspersky Container Security performs the following types of scans in CI/CD:

• Scanning images from the image registry. The solution runs a scan after a successful build and saves the image into the image registry.
• Scanning of images in TAR archives. A TAR archive is stored as a build artifact that the solution scans in the next build pipeline.
• Scanning a Git repository, which can be performed in one of the following ways:
  • for a project branch (individual development path) in the Git repository
  • for a commit (state snapshot or checkpoint in the project's timeline)

To scan an image from an image registry:

Start the scan by running a command in the following format:

/scanner [TARGET] --stdout

where:

• <TARGET>—full address of the image in the registry;
• <--stdout> is the output to the security event log.

To access the registry, you must set the login COMPANY_EXT_REGISTRY_USERNAME and password (token) COMPANY_EXT_REGISTRY_PASSWORD in the environment variables.
To use a certificate for secure connection to the registry, you must specify the certificate details in the COMPANY_EXT_REGISTRY_TLS_CERT environment variable as the following string in .PEM format: -----BEGIN CERTIFICATE-----\n... certificate data > ...\n-----END CERTIFICATE----- .

Examples of scanning images in GitLab CI/CD and Jenkins CI/CD.

To scan an image from a TAR archive:

1. Build an image and save it as a TAR archive using any application for creating containerized images.
2. Start the scan by running a command in the following format:

   /scanner [TARGET] --file --stdout

   where:

   • <TARGET>—path to the file with the image to be scanned
   • <--file>—flag indicating scanning of the TARGET file
   • <--stdout> is the output to the security event log.

   Example of a configuration file with settings for scanning a TAR archive

   stages:

   - build_tar

   - scan_tar

   - push_image

   build_tar:

   stage: build_tar

   tags:

   - k8s

   - docker

   image:

   name: gcr.io/kaniko-project/executor:v1.9.0-debug

   entrypoint: [""]

   dependencies:

   - scan_source_branch

   - scan_source_commit

   script:

   - mkdir -p /kaniko/.docker

   - echo "${DOCKER_AUTH_CONFIG}" > /kaniko/.docker/config.json

   - /kaniko/executor

   --context "${CI_PROJECT_DIR}"

   --dockerfile "${CI_PROJECT_DIR}/Dockerfile"

   --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

   --compressed-caching=false

   --build-arg GITLAB_USER=gitlab-ci-token

   --build-arg GITLAB_TOKEN=${CI_JOB_TOKEN}

   --no-push

   --tarPath=image.tar

   artifacts:

   paths:

   - image.tar

   expire_in: 2 hours

   scan_tar:

   stage: scan_tar

   tags:

   - k8s

   - docker

   dependencies:

   - build_tar

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - /scanner image.tar --file --stdout

   artifacts:

   paths:

   - image.tar

   expire_in: 2 hours

   push_image:

   stage: push_image

   tags:

   - k8s

   image:

   name: gcr.io/go-containerregistry/crane:debug

   entrypoint: [""]

   dependencies:

   - scan_tar

   script:

   - mkdir -p $HOME/.docker

   - echo "${DOCKER_AUTH_CONFIG}" > $HOME/.docker/config.json

   - /ko-app/crane push image.tar "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

To scan the Git repository:

1. In the configuration file of the Git repository, in the environment variables specify the token to access the repository (GITHUB_TOKEN or GITLAB_TOKEN).
2. Start the scan by running a command in the following format:

   /scanner [TARGET] --repo [--branch BRANCH] [--commit COMMIT] --stdout

   where:

   • <TARGET>—web address (URL) of the Git repository
   • <--repo> —flag indicating scanning of the TARGET file
   • <--branch BRANCH>—branch of the repository to be scanned
   • <--commit COMMIT>—hash of the commit to be scanned
   • <--stdout> is the output to the security event log.

   Example of a configuration file with environment variables for scanning an image from a Git repository

   stages:

   - scan_source_branch

   - scan_source_commit

   scan_source_branch:

   stage: scan_source_branch

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   tags:

   - k8s

   - docker

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - GITLAB_TOKEN=${CI_JOB_TOKEN} /scanner --repo ${CI_REPOSITORY_URL} --branch ${CI_COMMIT_BRANCH} --stdout

   scan_source_commit:

   stage: scan_source_commit

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   tags:

   - k8s

   - docker

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - GITLAB_TOKEN=${CI_JOB_TOKEN} /scanner --repo ${CI_REPOSITORY_URL} --commit ${CI_COMMIT_SHA} --stdout

To scan the

To scan the file system,

Start the scan by running a command in the following format:

/scanner [TARGET] --sources --stdout

where:

• <TARGET>– path to the file folder for scanning
• <--sources> – flag indicating the need to scan files in the file system
• <--stdout> is the output to the security event log.

Example of a configuration file with variables used to scan files in the file system

Scan results can be viewed in Resources → CI/CD, or downloaded in the .SPDX, .JSON, and .HTML formats.

Configuring integration with GitLab CI/CD

This example uses a specific scanner image with the built-in vulnerability databases located in the image registry of the Kaspersky Container Security manufacturer.

To use the image scanning feature in the GitLab CI/CD process, you should enable the use of the GitLab Container Registry.

Integration configuration includes the following steps:

1. Authorization of GitLab CI/CD in the image registry of the Kaspersky Container Security manufacturer.
   1. On the cluster operator's workstation, prepare a Base64 hash of the authorization data by running the following command:

      printf "login:password" | openssl base64 -A

      where login and password are the user name and password of an account in the image registry of the Kaspersky Container Security manufacturer.

   2. In the GitLab CI/CD environment variables, create the DOCKER_AUTH_CONFIG variable (in the GitLab repository select Settings → CI/CD, click the Expand button to expand Variables, and then click the Add variable button).
   3. Specify the variable in the following form:

      {

      "auths": {

      "repo.cloud.example.com": {

      "auth": "base64hash"

      }

      }

      }

      where base64hash is the string obtained in step 1a.

2. Authorization of requests from GitLab CI/CD when sending data to Kaspersky Container Security.
   1. Copy the API token on the My profile page.
   2. Specify the copied API token value in the API_TOKEN variable in the .gitlab-ci.yml configuration file.
3. Adding the image scanning stage to the CI/CD process.

   To add scanning to the CI/CD pipeline, you should add the following lines to the .gitlab-ci.yml file:

   1. Add information about the scanner image that contains databases of vulnerabilities and other malicious objects after the code build stage in the following form:

      scan_image:

      stage: scanner

      image:

      name: repo.cloud.example.com/repository/company/scanner:v2.0-with-db

      entrypoint: [""]

      pull_policy: always

      We recommend that you specify always for the pull_policy parameter to receive relevant builds with updated databases of vulnerabilities and other malicious objects for each scan.

   2. Specify the tag, build ID, pipeline ID and API token for authorization of the CI/CD scanner requests to Kaspersky Container Security as follows:

      SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

      BUILD_NUMBER: ${CI_JOB_ID}

      BUILD_PIPELINE: ${CI_PIPELINE_ID}

      API_TOKEN: <API token value>

      The example here contains the master tag, you can also specify another tag.

   3. If you configure scanning for a private repository, specify the authorization data to ensure the scanner can access an image. The authorization data can be set as variables.

      COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

      COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   4. To use a certificate for secure connection to the registry, specify the certificate data in the COMPANY_EXT_REGISTRY_TLS_CERT environment variable as a string in the .PEM format:

      -----BEGIN CERTIFICATE-----\n... <certificate details> ...\n-----END CERTIFICATE-----.

   5. Specify the following parameters of communication using a proxy server:

      HTTP_PROXY – <proxy server for HTTP requests>

      HTTPS_PROXY – <proxy server for HTTPS requests>

      NO_PROXY – <domains or appropriate domain masks to be excluded from proxying>

   6. If necessary, specify a variable to check the data receiving server in CI/CD using the CA certificate of the Ingress controller:

      API_CA_CERT: ${KCS_CA_CERT}
       
      The CA certificate of the Ingress controller is specified in the text field as a string in the .PEM format: 
       
      ----- BEGIN CERTIFICATE ----- \ n... <certificate details> ...\ n ----- END CERTIFICATE -----
       
      If the API_CA_CERT variable is not set, scanning will start but will not be completed. 
       
      Use of the CA certificate of the Ingress controller allows the scanner running in CI/CD to verify the authenticity of the data receiving server.
       
      If you use a self-signed certificate, or want to skip checking the data receiving server using the CA certificate of the Ingress controller, specify the value of the variable to skip the check as follows:
       
         SKIP_API_SERVER_VALIDATION: 'true'
       

   7. Specify the web address of the API host server for Kaspersky Container Security:

      API_BASE_URL – <web address>

      variables:

      API_BASE_URL: ${API_BASE_URL}

      script:

      - /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > artifact-result.json

      artifacts:

      paths:

      - artifact-result.json

After configuring integration with an external registry, you can scan images within the CI/CD process, including scanning in SBOM mode. Scan results can be viewed in Resources → CI/CD, or downloaded in the .SPDX, .JSON, and .HTML formats.

Configuring integration with Jenkins CI/CD

Configuring integration with Jenkins CI / CD consists of the following steps:

1. Authorization of Jenkins CI/CD in the image registry of the Kaspersky Container Security manufacturer. To do so, on the cluster operator's workstation, prepare a Base64 hash of the authorization data by running the following command:

   printf "login:password" | openssl base64 -A

   where login and password are the user name and password of an account in the image registry of the Kaspersky Container Security manufacturer.

2. Authorization of Kaspersky Container Security API. To perform authorization, complete the following steps:
   1. Copy the API token on the My profile page.
   2. Specify the copied API token value in the API_TOKEN variable in the Jenkinsfile configuration file.
3. Authentication of the data receipt server in CI/CD using the CA certificate of the Ingress controller. To perform authentication, in the Jenkinsfile configuration file, specify one of the following variables:
   1. -e API_CA_CERT=${KCS_CA_CERT} means the authentication is performed, and the scanner started in CI/CD can make sure the receiving server is authentic.
   2. -e SKIP_API_SERVER_VALIDATION=true means authentication of the receiving server using the CA certificate of the Ingress controller is not performed.
4. Creating Jenkins environment variables.

   To create environment variables, add the following lines to Jenkinsfile:

   1. Add information about the container registry where the scanner is located as follows:

      LOGIN: the name of the account in the scanner registry

      PASS: the password for the scanner registry

   2. If you configure scanning for a private repository, specify the following authorization data to ensure the scanner access to an image:

      COMPANY_EXT_REGISTRY_USERNAME: the name of the account in the registry of the scanned image

      COMPANY_EXT_REGISTRY_PASSWORD: the password for the registry of the image being scanned

   3. To use a certificate for secure connection to the registry, specify the certificate data in the COMPANY_EXT_REGISTRY_TLS_CERT environment variable as a string in the .PEM format:

      -----BEGIN CERTIFICATE-----\n... <certificate details> ...\n-----END CERTIFICATE-----.

   4. Specify the following variables for communication using a proxy server:

      HTTP_PROXY – <proxy server for HTTP requests>

      HTTPS_PROXY – <proxy server for HTTPS requests>

      NO_PROXY – <domains or appropriate domain masks to be excluded from proxying>

5. Adding information to start the scanner. Information for starting the scanner that contains databases of vulnerabilities and other malicious objects is added to the Jenkinsfile configuration file in the form of a declarative or scripted pipeline.

   Example of information for starting the scanner in the form of a declarative pipeline

   pipeline {

   agent any

   stages {

   stage('run scanner') {

   steps {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.cust02.int.example.com/ -e SKIP_API_SERVER_VALIDATION=true -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v2.0.0-with-db jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

   }

   }

   Example of data for starting a scanner in the form of a scripted pipeline

   node {

   stage ('run scanner') {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.cust02.int.company.com/ -e API_CA_CERT=${KCS_CA_CERT} -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v2.0.0-with-db jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

6. Generating an artifact for downloading.

   You can generate an artifact for downloading in the .HTML, or .JSON format to receive the scan results. You can specify an artifact format in --stout as follows:

   pipeline {

   agent any

   stages {

   stage('run scanner') {

   steps {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.int.company.com -e SKIP_API_SERVER_VALIDATION=true -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v2.0.1-lite jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

   stage('archive') {

   steps {

   archiveArtifacts artifacts: 'result.html'

   }

   }

   }

   }

   To generate a .JSON artifact, rewrite the --html --stdout> result.html' line in the example above as follows:

   --stdout > result.json',

   and in the archiveArtifacts artifacts line, specify the file name in the defined format: 'result.json'.

   Scan results can be obtained in the format you specified and can also be viewed in the Resources → CI/CD section.

Configuring integration with TeamCity CI/CD

To configure integration with TeamCity CI/CD:

1. Copy the API token on the My profile page to authorize the Kaspersky Container Security API in TeamCity.
2. In the settings menu in the TeamCity web interface, select Build Configuration Home → Parameters.
3. Click Add new parameters to add the values of the following environment variables:
   • API_TOKEN— specify the copied value of the Kaspersky Container Security API token.
   • API_BASE_URL — specify the URL of Kaspersky Container Security.
   • RUST_BACKTRACE — If necessary, specify full to use backtracing.
   • SKIP_API_SERVER_VALIDATION — specify true if you are using a self-signed certificate or if you need to skip authentication of the receiving server using the CA certificate of the Ingress controller.
   • COMPANY_EXT_REGISTRY_USERNAME – specify the account name in the registry of the scanned image.
   • COMPANY_EXT_REGISTRY_PASSWORD – specify the password for the registry of the scanned image.
   • COMPANY_EXT_REGISTRY_TLS_CERT – specify details of the certificate for secure connection to the registry.

     The certificate details are specified as a string in the .PEM format:
     -----BEGIN CERTIFICATE-----\n... <certificate details> ...\n-----END CERTIFICATE-----.

   • HTTP_PROXY – a proxy server for HTTP requests
   • HTTPS_PROXY – a proxy server for HTTPS requests
   • NO_PROXY – domains or appropriate domain masks to be excluded from proxying
4. Go to the Build Configuration Home → Build Step: Command Line section and click Add build step to add a build step.
5. In the window that opens, specify the following settings of the build step:
   • In the Runner type drop-down list, select Command Line.
   • In the Run drop-down list, select Custom script.
   • In the Custom script field, specify the path to the container for scanning (for example, /bin/sh /entrypoint.sh nginx:latest).
6. Under Docker Settings, specify the following settings:
   • In the Run step within Docker container field, specify the address of the scanner in the Docker registry. For example, company.gitlab.cloud.net:5050/companydev/example/scanner:v2.0.0-with-db.
   • In the Additional docker run arguments field, increase the privilege value to --privileged.
7. Click Save to save the settings.
8. Click Run in the upper-right corner of the page to start the build.
9. If necessary, download the scan results artifact, which is available on the Artifacts tab on the build scan results page in the TeamCity web interface.

Defining the path to container images

To start scanning, the solution needs to determine the path to the container images that need to be scanned. The path to container images can be specified in two ways:

• By specifying an image tag after the registry name, repository name, and image name. The tag is a changeable and easy-to-read description of the image.

  In this case, the path looks as follows: <registry>/<repository>/<image name>:<tag>. For example, http://docker.io/library/nginx:1.20.1.

• By specifying an image digest after the registry name, repository, and image name. A digest is an integral internal property of an image, specifically a hash of its contents (the SHA256 hash algorithm is used).

  When using a digest, the path is formed as follows: <registry>/<repository>/<image name><digest>. For example, http://docker.io/library/nginx@sha256:af9c...69ce.

A tag can match different digests, whereas digests are unique for each image.

Depending on the method used to specify the image path, Kaspersky Container Security performs one of the following actions before scanning:

• Converts the tag to a trusted digest.
• Checks whether the digest specified in the image path is trusted. A digest is considered trusted if it ensures the required degree of confidence in maintaining the desired protection relative to the object encoded using the hash algorithm.

Only trusted digests are sent to the container runtime.

Before running a container, the content of the image is compared with the received digest. To recognize a digest as trusted and the image as not corrupted, Kaspersky Container Security checks the integrity and authenticity of the image signature.

Monitoring the integrity and origin of images

When scanning images in CI/CD, Kaspersky Container Security protects against image spoofing at the registry level. The integrity and origin of images of containers deployed in an orchestrator cluster is controlled by verifying image signatures, starting at the build stage in CI.

Image integrity is monitored in two stages:

• Container images are signed after they are created. This process is implemented using external signature applications.
• Image signatures are checked before images are deployed.

  The solution saves a signature key, which is based on the SHA256 hash function and used as the code for signature validation. When deployed in an orchestrator, Kaspersky Container Security asks the signature server to confirm the authenticity of the signature.

Kaspersky Container Security checks image signatures as follows:

1. In the Administration → Integrations → Image signature validators section, you can configure the settings for integrating the solution with external image signature validation applications.
2. In the Policies → Runtime → Policies section, a runtime policy is added to protect the content of the image. This runtime policy validates the authenticity of signatures. Digital signatures are validated based on the configured image signature validators.
3. The orchestrator starts image deployment and uses a
   dynamic admission controller

   A configurable controller to access Kubernetes that helps enforce policies and supports the management and control system.

   to make a deployment request to the agent (kube-agent).

   To send the request to the Kaspersky Container Security agent, configure the dynamic admission controller in the values.yaml configuration file.

4. Based on the applicable runtime policy, the agent checks the signature validation settings configured in the Administration → Integrations → Image signature validators section.
5. If the check confirms the authenticity and validity of the signature, the solution allows image deployment. Otherwise, deployment is blocked.

Running the scanner in SBOM mode

Kaspersky Container Security allows you to start a scanner to check images for vulnerabilities in

The advantages of using SBOM are the following:

• Less resources required to scan images for vulnerabilities.
• Reduced scanning time due to automatic verification of correct operation and proper use of solution components.
• Capability to scan all existing vulnerabilities in an image without exceptions.
• High reliability of scanning results.

In CI/CD, the scanning process consists of two stages: receiving an SBOM file and scanning an image based on the received SBOM file. The image scanning process is implemented as follows:

• The CI/CD scanner generates a list of image components and sends the generated artifact to Kaspersky Container Security.
• Using the image handler, the solution forwards the received SBOM file to the scanner for scanning.

  To scan in SBOM mode, Kaspersky Container Security runs a scanner with pre-installed databases containing information about vulnerabilities and other malicious objects (scanner:v2.0-with-db, scanner:v2.0-with-db-java).

To scan images in CI/CD, you must specify the values of the following environment variables in the file:

• API_TOKEN – the value of the Kaspersky Container Security API token is specified.
• API_BASE_URL – Kaspersky Container Security URL is specified.
• API_CA_CERT – details of the CA certificate of the Ingress controller are specified, which allows the scanner running in CI/CD to verify the authenticity of the data receiving server. If you use a self-signed certificate, or want to skip checking the data receiving server using the CA certificate of the Ingress controller, the value of the variable to skip the check is provided as follows:

  SKIP_API_SERVER_VALIDATION: 'true'

• COMPANY_EXT_REGISTRY_USERNAME – specify the account name in the registry of the scanned image.
• COMPANY_EXT_REGISTRY_PASSWORD – specify the password for the registry of the scanned image.
• COMPANY_EXT_REGISTRY_TLS_CERT – specify details of the certificate for secure connection to the registry.

  The certificate details are specified as a string in the .PEM format:
  -----BEGIN CERTIFICATE-----\n... <certificate details> ...\n-----END CERTIFICATE-----.

• HTTP_PROXY – a proxy server for HTTP requests
• HTTPS_PROXY – a proxy server for HTTPS requests
• NO_PROXY – domains or appropriate domain masks to be excluded from proxying

For subsequent scanning, Kaspersky Container Security generates a report in the CycloneDX format. You can also generate an artifact with SBOM to download within the CI/CD process in the

To generate an SBOM file in the .SPDX format when the scanner operates with SBOM creation:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --sbom --spdx --stdout > example.spdx

where:

<--sbom> indicates the creation of an SBOM file.

<--spdx> indicates that an artifact is generated in the .SPDX format.

<--stdout > example.spdx> indicates data output to a file in the .SPDX format.

To generate an SBOM file in the .СDX format when the scanner operates with SBOM creation:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --sbom --cdx --stdout > example.cdx.json

where:

<--sbom> indicates the creation of an SBOM file.

<--cdx> indicates that an artifact is generated in the .CDX format.

<--stdout > example.cdx.json> indicates data output to a file in the .JSON format.

The resulting file (for example, example.cdx.json) is specified as an artifact: artifacts: paths:

Scanning using an SBOM file is only applicable when scanning an image for vulnerabilities. If your CI/CD process requires scanning for other risks and threats (such as misconfigurations), you must separately run the corresponding scanning and add its results to the image handler in addition to the SBOM file.

Running the scanner in lite SBOM mode

Kaspersky Container Security allows you to start a scanner to check images for vulnerabilities in the lite SBOM mode. In this case, the solution scans a specially created SBOM file, and the results of this scan become available at the CI/CD stage.

Data from listening to and intercepting network traffic must be securely transferred between the CI/CD environment and the solution.

You can generate an artifact for download in the .SPDX, .HTML, .JSON or .CDX format to receive the results.

Scan results can be obtained in the format you specified and can also be viewed in the Resources → CI/CD section.

Running a scanner in GitLab

To start the scanner in lite SBOM mode in GitLab, when configuring image scanning in CI/CD process, edit the .gitlab-ci.yml configuration file as follows:

1. Add information about the image of the scanner that is started for image scanning in CI/CD as follows:

   scan_image:

   stage: scanner

   image:

   name:repo.cloud.example.com/repository/company/scanner:v.2.0.0-lite

   entrypoint: [""]

   pull_policy: always

2. Specify the orchestration platform tag as follows:

   k8s

   In the example provided, the k8s tag is specified for Kubernetes, you can also specify the tag for another supported orchestration platform.

3. Specify such variables as the build ID, image registry data of the scanned image and certificate for secure connection to this registry, pipeline ID, and API token for authorization of requests from the CI/CD scanner in Kaspersky Container Security as follows:

   SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

   COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

   COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   COMPANY_EXT_REGISTRY_TLS_CERT: ${COMPANY_EXT_REGISTRY_TLS_CERT}

   BUILD_NUMBER: ${CI_JOB_ID}

   BUILD_PIPELINE: ${CI_PIPELINE_ID}

   API_TOKEN: <API token value>

   HTTP_PROXY – <proxy server for HTTP requests>

   HTTPS_PROXY – <proxy server for HTTPS requests>

   NO_PROXY – <domains or appropriate domain masks to be excluded from proxying>

   The details of the certificate for secure connection to the image registry in the COMPANY_EXT_REGISTRY_TLS_CERT variable are specified as a string in the .PEM format:
   -----BEGIN CERTIFICATE-----\n... certificate details > ...\n-----END CERTIFICATE----- .

4. If necessary, specify a variable for scanning the API certificate of the solution:

   API_CA_CERT: ${KCS_CA_CERT}

   If the API_CA_CERT variable is not set, scanning will start but will not be completed.

5. Specify the web address of the API host server for Kaspersky Container Security:

   API_BASE_URL: <web address>

6. Specify the command to create an artifact when the scanner is started in one of the following supported formats:
   • To generate an artifact in the .JSON format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > artifact-result.json

     artifacts:

     paths:

     - artifact-result.json

   • To generate an artifact in the .HTML format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --html --stdout > artifact-result.html

     artifacts:

     paths:

     - artifact-result.html

   • To generate an SBOM artifact in the .SPDX format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --spdx --stdout > artifact-result.spdx

     artifacts:

     paths:

     - artifact-result.spdx

   • To generate an SBOM artifact in the .JSON format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --cdx --stdout > artifact-result.cdx.json

     artifacts:

     paths:

     - artifact-result.cdx.json

Example of the scanner configured to operate in the lite SBOM mode and the artifact generation in the .HTML format in GitLab

Running a scanner outside of the CI / CD process

In case of limited resources, you can run the Kaspersky Container Security scanner apart from the worker nodes in the CI/CD process. For example, by using the docker run command on a Docker node, or as a Job in a Kubernetes cluster.

To save resources to the greatest extent possible, we recommend using the scanner: 2.0.0-lite image, as it does not contain vulnerability databases and sends the SBOM file based on the target image scan results to the solution using the API.

To start Kaspersky Container Security scanner outside the CI/CD process, you must specify the following mandatory parameters:

• API_TOKEN: <API token value> is the Kaspersky Container Security user token for authentication in the API interface of the solution.
• API_BASE_URL: <web address> is a link to access the API interface of Kaspersky Container Security. The interface can be accessed using the HTTP and HTTPS protocols, depending on the environment variables of the deployed solution.
• API_CA_CERT: <certificate in the .PEM format> is a variable for validation of the API certificate of the solution.
• SKIP_API_SERVER_VALIDATION = true - a variable that, if necessary, can be specified to skip the validation of the API certificate of Kaspersky Container Security.

You can also specify additional parameters for the scanner operation:

• COMPANY_EXT_REGISTRY_USERNAME: <registry user name> is the name of the user of the registry where the image to be checked by the scanner is stored.
• COMPANY_EXT_REGISTRY_PASSWORD: <registry user password> is the password of the user of the registry where the image to be checked by the scanner is stored.
• BUILD_NUMBER: <ID of the build number> is the ID that is used to track the build number in the solution interface. Kaspersky Container Security displays the number in the CI\CD process scan results.
• BUILD_PIPELINE: <pipeline number ID> is the identifier that is used to track the pipeline number in the solution interface. Kaspersky Container Security displays the number in the CI\CD process scan results.
• HTTP_PROXY: <proxy server for HTTP requests> is a variable that indicates the use of an HTTP proxy server when access to external resources is required
• HTTPS_PROXY: <proxy server for HTTPS requests> is a variable that indicates the use of an HTTPS proxy when access to external resources is required
• NO_PROXY: <domains or masks corresponding to domains that are used for exclusion from proxying> is a variable that indicates the locally available resources if a proxy server is used.

Running a scanner in Docker

Running the scanner as a Job in a Kubernetes cluster

Getting scan results in JSON or HTML format

When using Kaspersky Container Security to scan images in CI/CD, you can generate and save an artifact with the scan results within your CI/CD platform. This can be done using a configuration file of the external repository system that is integrated with the solution. For example, you can use a .gitlab-ci.yml configuration file in GitLab.

You can generate an artifact containing scan results in the following scenarios:

• When the scanner conducts a complete CI/CD scan - scanning results file can be generated in the .HTML format or the .JSON format.
• When the scanner operates with SBOM creation - file containing scanning results can be generated in the .SPDX format or the .JSON format.

To generate a scan results file in .HTML format:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --html --stdout > example.html

where:

<--html> indicates that an artifact is generated in .HTML format.

<--stdout > example.html> indicates data output to a file in .HTML format.

To generate a scan results file in .JSON format when performing a complete CI/CD scan:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > example.json

where:

<--stdout > example.json> indicates data output to a file in .JSON format.

The resulting file (for example, example.json) is specified as an artifact: artifacts: paths:

Specifying secrets when starting a scan

When starting a scan job in the CI/CD process, the registry containing the scanner image (the lite or with-db scanner for the corresponding version of Kaspersky Container Security) can be accessible only after authorization. For authorization, you can pass the required secrets in the scan job.

To be authorized for access to the registry when starting a scan job:

1. Create a secret:

   kubectl create secret docker-registry ci-creds --docker-server=client.repo.example.com --docker-username=username --docker-password=password

2. In the scan job, specify the value of the imagePullSecrets variable:

   imagePullSecrets:

   - name: ci-creds

3. Start the scan job.

   Example of a scan job with secrets for authorization

   kind: Job

   metadata:

   name: my-job

   spec:

   template:

   spec:

   containers:

   - name: my-container

   image: client.repo.example.com/scanner:master

   command: ["/bin/sh"]

   args: ["entrypoint.sh", "apline:latest"]

   env:

   - name: COMPANY_EXT_REGISTRY_USERNAME

   value: another_username

   - name: COMPANY_EXT_REGISTRY_PASSWORD

   value: another_password

   - name: API_BASE_URL

   value: https://some.kcs.env.example

   - name: API_TOKEN

   value: kcs_blablabla

   - name: SKIP_API_SERVER_VALIDATION

   value: 'true'

   imagePullPolicy: Always

   restartPolicy: Never

   imagePullSecrets:

   - name: ci-creds

   backoffLimit: 0

In this example, the scan job contains the following secrets:

• The secret for downloading the scanner image (specified in the imagePullSecrets variable).
• The password for downloading the image to be scanned if access to the relevant registry is restricted (specified in the COMPANY_EXT_REGISTRY_PASSWORD variable).

You can omit these passwords if the registry that the solution gains access to when running a scan job is accessible without authorization.

Configuring integration with image signature validators

Kaspersky Container Security can verify the authenticity and validity of the digital signatures of images. To use this functionality, you need to configure integration of the solution with one or more external signature applications. The specifics of signing an image digest, the location of signatures, and protecting signatures depend on the signature application you have selected. The solution supports two configurable external signature validation applications:

• Notary v1 is a web service developed by Docker that is used to ensure the security of containers at various stages of their life cycle, including the creation and subsequent storage of signatures.
• Cosign is a web service designed to create signatures for containers, verify signatures, and place signed containers in repositories. The tool was developed as part of the
  Sigstore

  This project aimed to develop and provide tools and services for the verification of software through the use of digital signatures. Sigstore also maintains a public registry to confirm the authenticity of changes to an image.

  project.

You can configure integration with an image signature validator in the Administration → Integrations → Image signature validators section.

Viewing the list of integrations with signature validators

In the Administration → Integrations → Image signature validators section, a table of all configured integrations with image signature validators is displayed.

The table displays the following information about the integrated image signature validators:

• Name of the validator
• Description, if one was specified when creating the integration
• Type of the image signature validator—Notary v1 or Cosign.
• Web address to which the image signature validator connects

In the table, you can:

• Add new integrations with signature verification modules. Click Add signature validator above the list to open the integration settings window.
• View and edit the settings for integration with an image signature verification module. You can open the editing window by clicking the link on the verification module name.
• Remove an integration with an image signature validator.

Adding an integration with an image signature validator

To add an integration with an image signature validator:

1. In the Administration → Integrations → Image signature validators section, click the Add signature validator button.

   The integration settings window opens.

2. In the General information section, enter a policy name and, if necessary, a policy description.
3. In the Type section, select one of the following signature validators:
   • Notary v1.
   • Cosign.
4. Depending on the selected signature validator, specify the server authentication credentials:
   • For Notary v1, specify the following settings:
     • Web address – the full web address of the server where image signatures are stored.
     • Signature server authentication secret name – the name of the orchestrator secret with credentials for accessing the server where image signatures are stored.

       The secret must be in the Kaspersky Container Security namespace.

     • Certificate – a self-generated certificate for the server where signatures are stored. The certificate is provided in .PEM format.
     • Delegations – list of signature holders participating in the signing process.
     • Under Trusted roots, specify the pairs of all public keys that the solution will check during signature verification. A key pair includes the name and value of the key.

       If necessary, you can add additional keys by clicking the Add key pair button. The solution supports up to 20 key pairs.

   • For Cosign, specify the following settings:
     • Signature server authentication secret name – the name of the orchestrator secret with credentials for accessing the server where image signatures are stored.

       The secret must be in the Kaspersky Container Security namespace.

     • Certificate – a self-generated certificate for the server where signatures are stored. The certificate is provided in .PEM format.
     • Under Trusted roots, specify the pairs of all public keys that the solution will check during signature verification. A key pair includes the name and value of the key.

       For Cosign, specify the public keys for the ECDSA or RSA algorithms provided by cosign.pub.

       If necessary, you can add additional keys by clicking the Add key pair button. The solution supports up to 20 key pairs.

     • In the Signature requirements section, specify the minimum number of signatures and signature holders who must sign the image.
5. Click the Save button in the top of the window to save the settings for integration with an image signature validator.

You can use the configured integration in runtime policies to ensure protection of the image content.

Viewing and editing information about integration with an image signature validator

To view and edit the settings for integration with an image signature validator:

1. In the Administration → Integrations → Image signature validators section, click the integration name link in the list of integrations with signature validators.
2. If necessary, in the window that opens, edit the integration settings, which depend on the selected signature validator, as follows:
   • For Notary v1, you can modify the following settings:
     • Validator name.
     • Description.
     • URL.
     • Signature server authentication secret name.
     • Certificate.
     • Delegations.
     • Key name.
     • Key value.
   • For Cosign, you can modify the following settings:
     • Signature server authentication secret name.
     • Certificate.
     • Key name.
     • Key value.
     • Threshold.
     • Required signers.
3. If necessary, add key pairs by clicking the Add key pair button.
4. Click the Save button in the upper part of the window.

Removing an integration with an image signature validator

To remove an integration with an image signature validator:

1. Open the list of the configured integrations with image signature validators.
2. Select the integration that you want to delete by selecting the check box in the row with the integration name.
3. Click Delete above the table.

   The Delete button becomes enabled after you select one or more integrations.

4. In the window that opens, confirm the deletion.

Setting up integration with notification outputs

Kaspersky Container Security can notify users about events while operating in accordance with the response policy settings. To use the notification feature, you should set up an integration of Kaspersky Container Security with one or more notification outputs.

Kaspersky Container Security can use the following outputs:

• Email
• Telegram instant messaging system

Viewing the list of integrations with outputs

To view the list of configured integrations with outputs:

1. Go to the Administration → Integrations → Notifications section.
2. Depending on the type of notification you want, go to the Email tab or the Telegram tab.

The table with a list of all configured integrations displays the following information about existing integrations:

• Integration name.
• Updated by.
• Date and time of the last update.
• Status of the last connection to the output—Success or Error. If Error is displayed, the solution also displays a brief description of the connection error.

In the table, you can:

• Add new integrations with email or Telegram. Click Add integration above the table to open the integration settings window.
• View and edit the settings of integration with outputs. You can open the editing window by clicking the integration name link.

  In this window, you can also click Test connection to see if integration with an output is completed.

• Delete integration with outputs.

Adding email integrations

To add an email integration:

1. Under Administration → Integrations → Notifications, in the Email section, click Add integration.

   The integration settings window opens.

2. Specify the following information in the form:
   • Name of the integration — Displayed in the response policy settings.
   • User name and password of the account used to send messages.
   • SMTP server name.
   • E-mail encryption method.
   • Port that the SMTP server uses.
   • Email address of the message sender.
   • Email addresses of message recipients. You can enter one or more addresses in this field.
3. Click Test connection to see if a connection with email can be established.
4. Click Add to save the email integration settings.

Example email integration settings

You can use the configured integration in response policies.

Viewing information about email integration

To view and change an email integration:

1. In the Email section, under Administration → Integrations → Notifications, click the integration name link in the list of integrations.
2. In the editing window that opens, change the following integration settings if necessary:
   • Name.
   • User name.
   • Password of the user account that is used to send messages.
   • SMTP server name.
   • E-mail encryption method.
   • Port that the SMTP server uses.
   • Email address of the message sender.
   • Email addresses of message recipients.
3. Click Test connection to see if a connection with email can be established.
4. Click Save.

Adding Telegram integrations

To add a Telegram integration:

1. Under Administration → Integrations → Notifications, under Telegram, click Add integration.

   The integration settings window opens.

2. Specify the following information in the form:
   • Name of the integration — Displayed in the response policy settings.
   • ID of the chat to post the messages — you can get the ID in the following way:
     1. Write the first message to the message bot. The chat ID is generated the first time a message is sent.
     2. In the address bar of your browser, type:

        https://api.telegram.org/bot<token>/getUpdates

        where <token> is the token of the message bot.

     3. In the received .json response file, find the "ID" value in the "chat" object. This is the chat ID.

     After changing the message history visibility settings for new participants in a Telegram chat, the chat ID is also changed. In this case, you must change the Telegram integration settings and specify the new value for the chat ID.

   • Token of the message bot — you receive this token as a result of executing the /newbot command in the BotFather bot to create a bot. You can also get the token of a previously created bot by running the /token command.
3. Click Test connection to see if a connection with Telegram can be established.
4. Click Add to save the Telegram integration settings.

Example Telegram integration settings

You can use the configured integration in response policies.

Viewing and editing information about integration with Telegram

To view and change a Telegram integration:

1. Under Telegram in the Administration → Integrations → Notifications section, click the integration name link in the list of integrations.
2. In the editing window that opens, change the following integration settings if necessary:
   • Name.
   • Chat ID.
   • Bot token.
3. Click Test connection to see if a connection with Telegram can be established.
4. Click Save.

Deleting integrations with notification outputs

To delete email integration or Telegram integration:

1. Open the list of configured email or Telegram integrations in the Administration → Integrations → Notifications section.
2. Select the integration that you want to delete by selecting the check box in the row with the integration name.
3. Click Delete above the table.

   The Delete button becomes enabled after you select one or more integrations.

4. In the window that opens, confirm the deletion.

You cannot delete an integration that is used in one or more response policies.

Configuring LDAP server integration

Kaspersky Container Security lets you connect to servers of external

Connection to an external directory service over the LDAP protocol enables you to perform the following tasks:

• Configure user accounts to take into account data from an external directory service for working with Kaspersky Container Security.
• Correlate user roles in Kaspersky Container Security to groups of users from Active Directory. Users in these groups will be able to use their domain account credentials to log in to the solution web interface and access application functionality based on their assigned role.

  We recommended that you create these user groups in Active Directory in advance to allow them to complete authorization using their domain accounts in the Kaspersky Container Security web interface.
  An email address must be indicated for user accounts in Active Directory.

Creating LDAP server integration

To create an integration with an LDAP server:

1. In the Administration → Integrations → LDAP section, click the Connect server button.

   The LDAP server settings window opens.

2. Select certificate validation mode for connection to the LDAP server. By default, Certificate chain mode is specified and the certificates saved by Kaspersky Container Security during the first connection to the LDAP server are verified. You can also select Root certificate mode and enter your root certificate details in the corresponding text field.

   Do not change the default certificate validation mode unless you are using a root certificate to connect to the LDAP server.

3. Specify the following required settings:
   • Web address (URL) of your company's LDAP server.

     The web address of the LDAP server is specified as follows: ldap://<host>:<port>. For example: ldap://ldap.example.com:389.

   • The name and password of the technical user account.

     Bind DN is the distinguished name of the technical user account that is necessary for initial authentication and searching for a user in Active Directory.

     You can specify the name of the technical user account in full or in the <login@domain> format if your LDAP server supports this name format for authentication.

     In the Bind DN password field, you must enter the password corresponding to the specified account name.

     Before updating the solution, make sure that the Bind DN and Bind DN password fields are filled in. If these settings are not specified, LDAP server integration will not work.

   • Base DN is the name that uniquely identifies and describes a record of the LDAP directory server.

     For example, the base distinguished name for example.com is dc=example,dc=com.

4. If necessary, Kaspersky Container Security cane use available data to fill in the remaining fields of the integration creation form. To this end, depending on why you are creating the integration, do one of the following:
   • If you want to create an integration with the server using the LDAP protocol, click the Autofill as LDAP button.
   • If you want to configure the integration directly for the group in the Active Directory service that is associated with your role in Kaspersky Container Security, click the Autofill as Active Directory button.

   Kaspersky Container Security specifies attributes of parameter values, not the values themselves. For example, the solution specifies an attribute of the user name that can be used to find the user, not the user name directly.

   The solution populates the integration creation form with the following attributes of parameter values:

   • User filter for defining the user search settings in Active Directory.
   • Group filter for defining the group search settings in Active Directory.

     Kaspersky Container Security uses the most general filter values to ensure operation for virtually all possible configurations. When configuring User filter and Group filter, we recommend that you store only those attribute values that are used in Active Directory.

   • Under Base schema, the solution specifies the following settings:
     • Organizational unit name attribute
     • Distinguished name attribute
   • Under User lookup schema, the solution specifies the following settings:
     • User first name attribute.
     • User lastname attribute.
     • Group name attribute.
     • User username.
     • Group member.
     • User email attribute.
     • User member of.

   If necessary, you can edit the values specified by the solution in the integration creation form.

5. To check if the values are specified correctly, click Test connection.

   Kaspersky Container Security will display a notification informing you of the successful connection to the LDAP server or a failure to establish the connection.

6. Click Save.

If the LDAP server certificate changes, reconfigure the integration.

You can use the configured integration when creating and assigning user roles.

Viewing, configuring, or deleting an LDAP server integration

To view the LDAP server connection:

Go to the Administration → Integrations → LDAP section.

Kaspersky Container Security displays the following information about the connected LDAP server:

• The web address of the connected LDAP server.
• The status of the last server connection—Success, Not available, or Error. If Error is displayed, the solution also displays a brief description of the connection error.

To edit LDAP server integration settings:

In the Administration → Integrations → LDAP section, click the Edit settings button.

Kaspersky Container Security opens the page containing the form for LDAP server integration data.

To delete an integration with an LDAP server:

1. In the Administration → Integrations → LDAP section, click Delete integration.
2. In the window that opens, confirm the deletion.

Testing connection with LDAP server

To test connection with the LDAP server:

1. Go to the Administration → Integrations → LDAP section.
2. Do one of the following:
   • If the integration with the LDAP server is created, click the Test connection button.
   • If you are creating an integration with an LDAP server or editing its settings, click Test connection below the form for LDAP server integration data.

Kaspersky Container Security will display a notification informing you of the connection to the LDAP server or a failure to establish the connection.

Gaining access to Active Directory group

After the integration with the LDAP server is configured, you can specify an Active Directory group for each Kaspersky Container Security role. After authorizing their account credentials, the users from this group gain access to solution functionality based on their defined roles.

Configuring integration with SIEM systems

Kaspersky Container Security allows connecting to

Messages are sent to a SIEM system in the

CEF:0|Kaspersky|Kaspersky Container Security|2.0|PM-002|Process management|7|dpid=1846367 spid=1845879 flexString2=0ce05246346b6687cb754cf716c57f20f226e159397e8e5985e55b448cb92e3f flexString2Label=Container ID cs6=alpine cs6Label=Container name outcome=Success

The transmitted message consists of the following components:

• The
  Syslog

  A standard for sending and logging system event messages used for the UNIX and GNU/Linux platforms.

  header, which specifies the date, time, and host name.
• Prefix and CEF version number.
• Device vendor.
• Solution name.
• Solution version.
• Solution-generated unique event type code.
• Event description.
• Event severity assessment.
• Additional information, such as device IP address, event reason, event result, and event status.

For detailed information about the components, refer to the CEF message value matching table.

Matching of CEF message fields

CEF messages are sent in the English language.

The table below lists the man components of the header and body of CEF messages sent by Kaspersky Container Security.

Components and values of CEF message components

Additional information about an event which is transferred by Kaspersky Container Security

Creating an integration with a SIEM system

To add a SIEM integration:

1. In the Administration → Integrations → SIEM section, click Add SIEM.

   A sidebar is displayed, in which you can enter the parameters of SIEM system.

2. On the General tab, specify the following required parameters:
   • Name of the SIEM system.
   • Protocol for connecting to the SIEM system. TCP is selected by default.
   • Address of the SIEM system server in one of the following formats:
     • IPv4
     • IPv6
     • FQDN
   • Port for connecting to the SIEM system. You can specify ports 1 through 65535. The default setting is 514.
   • Event categories for which you want messages to be exported to the SIEM system. To configure this, select the check boxes next to one or more event categories from the following list:
     • Administration.
     • Alert.
     • CI/CD.
     • Policies.
     • Resources.
     • Scanners.
     • Admission controller.
     • Forensic data.
     • API.

       An advanced license is required to view events in the Resources, Scanners, Admission controller, and Forensic data categories.

     By default, all statuses are selected.

     Messages about selected event categories are sent to the specified SIEM system, regardless of whether it is linked to agent groups.

3. On the Agent group logs tab, select the check boxes next to one or more event types as part of node monitoring in the runtime.

   The log of event messages sent to the runtime environment can be very large, which can impact available disk space and network load.

4. If you want to verify the correctness of the specified SIEM integration parameters, click Test connection.

   The solution tests the connection to the SIEM system if the TCP connection protocol is selected. If the UDP connection protocol is selected, the Test connection button is disabled.

5. Click Save.

Linking agent groups with a SIEM system

You can link agent groups to SIEM systems while creating agent groups or editing their parameters in the Components → Agents section.

To link an agent group in Kaspersky Container Security, you must have sufficient rights to manage agent groups; you must also create and configure at least one SIEM integration.

Viewing and editing SIEM integration settings

To view a SIEM integration:

1. Open the list of SIEM integrations in the Administration → Integrations → SIEM section.
2. Click the integration name in the list of integrations.

To edit SIEM integration settings:

1. In the Administration → Integrations → SIEM section, click the integration name in the list of integrations.
2. If necessary, in the displayed sidebar, edit the integration parameters as follows:
   1. On the General tab, edit the following required parameters:
      • Name of the SIEM system
      • Protocol for connecting to the SIEM system
      • SIEM system server address
      • SIEM system connection port
      • Categories of events to be exported
   2. If necessary, on the Agent group logs tab, you can edit the list of network node monitoring event types selected for the runtime.
3. If TCP is used for the connection, click Test connection to see if the connection to the SIEM system is can be established.
4. Click Save.

Deleting an integration with a SIEM system

To delete a SIEM integration:

1. Open the list of configured SIEM integrations in the Administration → Integrations → SIEM section.
2. Select the integration that you want to delete by selecting the check box in the row with the integration name.
3. Click Delete above the table.

   The Delete button becomes enabled after you select one or more integrations.

4. In the window that opens, confirm the deletion.

Integrating with HashiCorp Vault

Kaspersky Container Security provides the ability to securely transfer passwords, tokens, and secrets using HashiCorp Vault, an external storage service. The solution generates pod annotations, which the Vault injector uses to mount the necessary secrets from storage at startup.

Kaspersky Container Security supports integration with Hashicorp Vault 1.7 or later.

Version 2.0 of Kaspersky Container Security supports working with HashiCorp Vault only in sidecar mode using sidecar containers; in this case, only the Kubernetes authentication method is supported.

If the service accounts for pods are not defined, and default service accounts are used, we recommend against assigning roles dedicated to the storage to such service accounts, in line with a critical security requirement.

Values of HashiCorp Vault settings are specified in the values.yaml configuration file and deployed when the Helm Chart package is launched.

HashiCorp Vault settings are configured in the values.yaml configuration file as follows:

• If the enabled setting in the vault block is set to false, integration with the vault is not used.
• If the enabled setting in the vault block is set to true, integration with the vault is enabled, and the values of the variables in the vault settings block take precedence.

The vault settings block contains the following sections:

• secret – to specify secrets and credentials.
• certificate – to specify certificates and certificate keys.

The secret section lists the paths to files that contain the secrets for the following parameters:

• Secrets of proxy servers for requests to the external information environment.
• Credentials for the PostgreSQL database.
• Credentials for an s3-compatible file storage for storing files that are generated by the solution.
• Credentials for the ClickHouse database management system.

Secrets are specified in key:value format

where:

• <key> is the name of the environment variable
• <value> is the full path to the secret in the secret storage, followed by the @ sign and the name of the key of the secret created in the storage.

For example: POSTGRES_USER: kv/secret/kcs/psql@POSTGRES_USER

To get a certificate, in the vault.certificate section, you must specify the following in the fields:

• To get a CA certificate, the ca setting is set to true. In this case, the path to access the certificate is formed based on the standard cert/ca path based on the name in the public key infrastructure (Public Key Infrastructure, PKI). If the CA certificate is not a root certificate, use the caList parameter to list all certificates, including the root certificate. For example:

  cert-ca:

  ca: true

  tls.crt: pki_kcs/cert/ca

  caList:

  - pki/cert/ca

• To generate certificates and keys, you need to specify the path from the PKI name with the standard issue path and the name of the created role. The common name (cn) and all possible alternative names (altname) are automatically added to the certificate. If necessary, the cn, altname and ipsans values can be specified manually as shown below for an external database:

  cert-pguser:

  cn: pguser

  altname: pguser,pguser.psql,pguser.psql.svc,pguser.psql.svc.cluster.local,localhost

  ipsans: 0.0.0.0,127.0.0.1

• To set the certificate lifetime, you need to specify the value of the ttl parameter. The default value is 8760 hours.

  The parameter value cannot be greater than the value set in the PKI HashiCorp Vault.

The certificate section also contains the paths to files that contain the following certificates and keys:

• CA certificate and client certificate for an external PostgreSQL database.
• Certificates required for the solution components:
  • CA certificate and CA certificate key for the admission controller.
  • Certificate and certificate key for the Kaspersky Container Security licensing module.
  • Certificate and certificate key for the module with the solution's main business logic.
  • Certificate and certificate key for the remote procedure call platform (GRPC).
  • Certificate and certificate key for the scanner server.
  • Certificate and certificate key for the scanner server API.
  • Certificate and certificate key for the update file server for private corporate networks.
  • Certificate and certificate key for s3-compatible file storage.
  • Certificate and certificate key for the event broker.
  • Certificate and certificate key for the agent broker.
  • Certificate and certificate key for the ClickHouse database management system.

HashiCorp Vault storage settings:

For Kaspersky Container Security to work with HashiCorp Vault, you must specify the values of the following configuration settings in the values.yaml configuration file:

• The enabled flag enables the integration with the storage. The vault.enabled = true value indicates that the integration with HashiCorp Vault is established; the values of environment variables are obtained from the storage. The default value is false.
• mountPath — path to mount secrets from the Vault to the pod. The default is /vault/secrets.
• role is the role to be used for authentication in the storage.

  When creating a role in Vault, you need to specify all existing values from the serviceAccount section in the values.yaml file.

• agentInitFirst — variable for defining the initialization queue of the init container. A value of true indicates that the pod first initializes the Vault init container. This value must be set when other containers in the initialization require prepopulated secrets to function. If it is set to false, the order of initialization of the containers is randomized. The default value is true.
• agentPrePopulate — variable for enabling the init container for prepopulating the shared memory with secrets before the containers are started. The default value is true.
• agentPrePopulateOnly — variable that indicates whether the init container will be the only one injected in the pod. If it is set to true, no sidecar container is added when the pod is run. The default value is false.
• preserveSecretCase — variable for preserving the case in the names of secrets when creating secret files. The default value is true.
• agentInjectPerms — variable that defines rights to access the mounted file with secrets from the storage. The default value is 0440 (owner and group have the read permission).
• annotations — instructions that configure the correct operation of the sidecar container. You can add instructions to the vault block for use by all Helm Chart components or specify them in the Architecture section separately for each component, for example:

  kcs-middleware:

  enabled: true

  appType: deployment

  annotations:

  vault.hashicorp.com/agent-limits-cpu: 200m

Limitations related to storage

There is a number of non-critical limitations when Kaspersky Container Security works with HashiCorp Vault:

• Integration with HashiCorp Vault works only with KV1/KV2 storages and Secrets Engine components for rotating PKI certificates.
• The solution does not support working with external components of the Secrets Engine, except for PKI Secrets.
• Kaspersky Container Security does not support dynamic processing of secrets. To get an updated secret, you have to restart the solution.
• If you are using Vault integration, you can specify credentials only for an external PostgreSQL database in the vault section. To use an internal PostgreSQL database, these credentials must be commented out.