Architecture

Sysdig Agent

Sysdig collects monitoring and security information from target entities. To achieve this, one Sysdig agent should be deployed in each host. These hosts can be:

• The nodes that make up a Kubernetes or OpenShift cluster.

• Virtual machines or bare metal on your physical premises.

• Living in a cloud environment, for example, Amazon Web Service (AWS), Google Cloud, IBM Cloud, and Azure.

The Sysdig agent can be installed as a container using a Helm chart, Kubernetes operator, and so on.

Once the agent is installed in the host, it starts collecting information from a variety of sources, such as:

• Running containers
• Container runtime
• The orchestration API, such as Kubernetes, OpenShift, and so on
• Metrics from defined Prometheus endpoints,
• Auto-detected JMX sources, StatsD, and integrations
• The host itself

The Sysdig agent maintains a permanent communication channel with the Sysdig backend, and sends messages containing the monitoring metrics, infrastructure metadata, and security events. The channel is secured with standard TLS encryption and transports data as binary messages. The agent uses this channel to transmit data, and to receive additional configuration from the backend, such as security runtime policies or benchmarks.

Sysdig Backend

For the Sysdig backend, you have a choice between:

• Using the SaaS version, managed transparently by Sysdig,
• Installing it directly on your premises. Neither choice affects the operations described below.

Once the agent messages are received in the backend, they are processed and extracted into data available to the platform, for example, as time series, infrastructure and security events, and infrastructure metadata.

The main components of the backend/platform include:

• Extraction and post-processing of the metric data from the agent, so that full time-series, with all the necessary infrastructure metadata, are available to you

• Maintenance of the infrastructure metadata (most notably Kubernetes state), so that all events and time series can be enriched and correctly grouped

• Storage of time-series and event data

• Processing of time-series data to calculate alert triggers

• Queuing the security events triggered by the agents to be shown on the event feed, notifying through the configured notification channels and alerts and forwarding via the Event Forwarder to external platforms like Splunk, Syslog or IBM Multicloud Manager (MCM) / Qradar

• Aggregating and post-processing other security, data such as container fingerprints that are used to generate container profiles, or security benchmark results

The Sysdig platform stores this post-processed data in a set of internal databases. The API service combines these to create the data views, such as dashboards, event feeds, vulnerability reports, and security benchmarks.

Sysdig APIs

The Sysdig platform provides several ways to consume and present its internal data. All APIs are RESTful, HTTP JSON-based, and secured using TLS. The same APIs are used to power the Sysdig front end, as well as any API clients (such as sdc-cli).

• Monitor API

  • User and Team management API

  • Dashboard API

  • Events API

  • Alerts API

  • Data API (proprietary Sysdig API for querying time-series data)

• Secure API

  • Image Scanning API

  • Security Events API

  • Activity Audit API

  • Secure Overview API

• PromQL API: Prometheus compatible HTTP API for querying time -series data

These enable different use cases:

• Access to the platform via the Sysdig user interface (UI)

• Programmatic input and extraction of data, i.e.

  • Automatic user creation

  • Terraform scripts to save or recover configuration state

  • Inline scanning to push scanning results from the CI/CD pipeline

  • Instrumentation using thesdc-cli.

• PromQL API interface that can be used to connect any PromQL-compatible solutions, such as Grafana.