Azure Pipelines

Several mechanics have been implemented to allow seamless integration with Azure Pipelines.

Azure Pipelines Hosted Runners Support

The most popular environment for running Azure Pipelines build is through hosted runners. As soon as a job is submitted, it is translated into a VM created by Azure and run on an Azure-backed cloud.

In short, Cimon Agent is runner-aware, which means it is aware of the runner environment and adapts itself accordingly. There are several ways in which the functionality reflects this:

• Hosted Runner Support - Cimon will be compatible with any Ubuntu-based hosted runner.
• Allowed Hosts - Azure-related hosts will be added automatically, including dev.azure.com, *.vsblob.visualstudio.com, etc.
• Ignored IPs - Ignoring internal IPs communication, such as the Azure metadata IP address 169.254.169.254, 127.0.0.1, and more.
• Performance - To improve the performance, it will track the descendant processes of the pipeline runner process, Agent.Worker in the case of Azure Pipelines (it will also track docker-related processes due to their relevance)
• Azure Pipelines Reporters - It will output the report according to the runner identified. In the Azure Pipelines case, that would be a job summary report.

Cimon Azure Pipelines Task

As part of Cimon, we provide a custom task for deploying agents seamlessly within any Azure Pipelines build. The task is reachable by installing the Cimon extension on the official marketplace, which can be found at https://marketplace.visualstudio.com/items?itemName=CycodeLabs.cimon.

The task is based on the NodeJS engine and contains simple pre and post scripts to start and gracefully shut down the agent's container. Cimon is run as a privileged container in detached mode and joins the runners' process and network namespaces to see all the processes and network connections on the host.

Usage

The core of the Azure Pipelines integration is installing Cimon simply by introducing the Cimon task in your Azure Pipelines Workflow as follows:

steps:
  - task: Cimon@0
    inputs:
      # Cimon client ID for authentication
      client-id: $(CIMON_CLIENT_ID)

      # Cimon secret for authentication
      secret: $(CIMON_SECRET)

      # Whether Cimon is run in detection only or prevention mode.
      # In prevention mode it will block forbidden network traffic
      # and possibly fail the corresponding job run.
      # Default: false
      prevent: ""

      # A comma or white space separated list of
      # allowed IP addresses
      allowedIps: ""

      # A comma or white space separated list of allowed domain names.
      # The left-most label can be the wildcard character (*) to match
      # multiple subdomains (e.g. *.example.com).
      #
      # The following domains are added implicitly for Azure Pipelines runner:
      # - dev.azure.com
      # - *.vsblob.visualstudio.com
      # - *.visualstudio.com
      allowedHosts: ""

      # Whether process tree is included in job summary.
      # For complex job definitions it may be way too verbose.
      # Default: false
      reportProcessTree: ""

      # Includes slack webhook endpoint to report findings.
      # Report is sent when security event found on prevent mode.
      slackWebhookEndpoint: ""

      # Log level (used for debugging Cimon)
      # Default: "info"
      logLevel: ""

      # Set of key=value pairs that describe Cimon features
      featureGates: ""

      # Fail the CI if Cimon encountered an error
      # Default: false
      failOnError: ""

Job Summary Report

Cimon uploads the final report as a job summary for the Azure Pipelines job, which is available in the "Extensions" tab. Additional info for how it works can be found here.

Running Cimon in a Container Environment

Cimon is fully compatible with containerized workflows, making it ideal for jobs using container-based runners on Azure Pipelines. To ensure Cimon runs smoothly within such an environment, the following conditions must be met:

• The container running the Azure Pipelines runner must be executed with --privileged mode to grant the necessary permissions for Cimon to monitor processes and network activities.
• curl, wget, and jq must be installed before running the Cimon task. These can be easily added using common package managers such as apt or yum. Due to Azure Pipelines’ container environment restrictions, you cannot install packages at runtime within a container, even with the --privileged flag. Therefore, these packages need to be pre-installed in the container image.

Steps for Running Cimon in Azure Pipelines Containerized Environment

1. Pre-build a Docker image that includes the necessary tools. Below is an example of a Dockerfile to create such an image:

FROM ubuntu:22.04

# Install dependencies
RUN apt-get update && apt-get install -y \
    jq \
    curl \
    sudo \
    wget && \
    rm -rf /var/lib/apt/lists/*

After building this image, push it to a container registry (e.g., Azure Container Registry or Docker Hub). We’ll assume the image has been pushed to myorg/ubuntu-with-deps:latest.

2. Create a service connection to the container registry in Azure Pipelines platform if it doesn’t already exist. This will allow Azure Pipelines to pull the image from the registry. Detailed instructions on creating a service connection can be found here. For this example, we'll assume the service connection is named registry-endpoint-name.

3. Use the pre-built image in your Azure Pipeline to run Cimon. Here’s an example of how to configure your pipeline:

trigger:
  - main

pool:
  vmImage: "ubuntu-latest"

jobs:
  - job: Build
    container:
      image: myorg/ubuntu-with-deps:latest
      options: --privileged
      endpoint: registry-endpoint-name

    steps:
      - task: Cimon@0
        displayName: Run Cimon Agent

      - script: |
          curl google.com
        displayName: "Test network connection"