Resource and Component Support

Resource Support

Kubernetes Workloads

Sysdig Secure provides runtime monitoring and vulnerability scanning for the following Kubernetes workload types using the Sysdig Cluster Shield:

• Pods
• Deployments
• StatefulSets
• DaemonSets
• Jobs
• CronJobs
• ReplicaSets
• ReplicationController
• init Containers and Side Cars

Kubernetes CronJobs

Starting with Cluster Shield version 1.16.0, Sysdig supports vulnerability scanning of Kubernetes CronJobs that are scheduled within the Kubernetes API during the standard metadata collection cycle.

Once a CronJob is scanned, the results are retained as long as the CronJob definition remains in the Kubernetes API. The CronJob is marked as a Running workload, even if the job is no longer actively running.

To verify CronJob scheduling and review scheduling details through the CronJob’s metadata and following configuration, see Sysdig Kubernetes Security and Posture Management.

apiVersion: batch/v1
kind: CronJob
metadata:
    labels:
        app: default
        name: example-trigger
    name: default-example-trigger
    namespace: default
spec:
    concurrencyPolicy: Allow
    jobTemplate:
        metadata:
            creationTimestamp: null
        spec:
            template:
                metadata:
                    creationTimestamp: null
                    labels:
                        app: default
                        name: example-trigger
...
    schedule: '*/10 * * * *'

Kubernetes Init Containers

Starting with Cluster Shield version 1.16.0, Sysdig supports vulnerability scanning of Kubernetes workload init containers. Kubernetes Init Containers are specialized containers that run before the application containers in a pod. These specialized containers always execute before the primary container of any replica within a Kubernetes workload.

Example 1

The following init container configuration runs pre-checks and waits for services to become available before the primary container starts. Additionally, there are also Kubernetes Sidecar Containers that continuously run throughout the lifecycle of the pod and its workloads across all replicas.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

Example 2

A sidecar container can act as a log-shipping mechanism that runs throughout the entire lifecycle of the pod. As such, these vulnerabilities are associated with the workload and are included in the Runtime Vulnerability Findings for that workload on the individual container, even if the init container is no longer running. These vulnerability findings remain visible in the Sysdig Platform until the workload definition is removed from the Kubernetes API.

Init containers inside Kubernetes workloads are often named with an -init suffix. However, it depends on your workload definition and naming conventions set by your development teams.

For best practices on using init containers and sidecar containers, refer to the Kubernetes Documentation.

The following example demonstrates this configuration:

apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
        - name: myjob
          image: alpine:latest
          command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      restartPolicy: Never
      volumes:
        - name: data
          emptyDir: {}

Non-Orchestrated or Non-Kubernetes Containers

For non-orchestrated or non-kubernetes containers, Sysdig supports scanning using the Host Scanner with Container Scanning enabled.

Supported Container Runtimes

Host Scanner

• Docker daemon
• ContainerD
• CRI-O

Cluster Shield

The Sysdig Cluster Shield supports any container runtime that Kubernetes will support. For supported Kubernetes runtimes, see the Kubernetes Supported Container Runtime documentation.

Standalone Hosts

For standalone hosts where a Supported Distributions is running, Sysdig Secure performs full host vulnerability scanning and monitoring. For more information, see Host Scanner Installation Guide.

Agentless Scanning for Cloud Hosts

Sysdig Secure provides agentless scanning capabilities for cloud providers, including:

AWS: Amazon EC2 instances running supported distributions
Azure: Microsoft Azure VM instances running supported distributions
Google Cloud: Google Compute Engine (GCE) instances running supported distributions

Agentless Scanning allows Sysdig Secure to discover vulnerabilities without the need to install agents directly on the hosts. To enable Agentless Scanning, see the Agentless Setup Guide.

Additionally, Sysdig Agentless scanning can also detect and scan running containers on Hosts Scanned Agentlessly that are running Supported Distributions.

CI/CD Pipeline

For CI/CD pipeline scanning, Sysdig provides a CLI-based scanner that can be easily integrated into your build pipeline to scan container images. For more information, see Sysdig CLI Scanner.

CLI Scanner Supported Container Image Formats and Loading Methods

Supported Container Image CPU Architectures

• linux/amd64
• linux/arm64
• linux/s390x

VM Component Deprecation and Supportability

Legacy Engine Components

All V1 Engine Components will be deprecated on January 1st, 2025. After this date, Sysdig will not apply defect fixes or security patches. Below are the replacement components for the affected items:

Affected Components

Scanning Engine Components

Certain components and versions used with the Sysdig Scanning Engine will reach end-of-life (EOL) or be considered out of support. Below are the affected components and their descriptions.

Affected Components