Kubernetes Agent - Delegate

The Delegate in OpsMx Delivery Shield is a lightweight Kubernetes-based agent that acts as the execution engine for all security scanning operations. It bridges the gap between the OpsMx gateway (the central control plane) and the target environments where your code, containers, and infrastructure actually live — executing scans securely within your own network perimeter, without exposing credentials or sensitive data to external systems.

Rather than relying solely on webhooks or external triggers, Delivery Shield's delegate architecture enables On-Demand Scanning — giving security and DevOps teams the ability to configure, trigger, schedule, and monitor vulnerability scans directly from the dashboard, at any time, against any registered repository or container registry.

What Is a Delegate?

A Delegate is an instance of the SSD Shield Agent — a set of Kubernetes components deployed into your cluster that:

• Receives scan configurations and instructions from the OpsMx gateway via gRPC

• Stores scan configurations as Kubernetes Custom Resource Definitions (CRDs) — persisting them across restarts

• Executes security scans using integrated scanners (Trivy, Grype, Semgrep)

• Manages scheduled, polling-based, and manually triggered scan jobs

• Returns results to the gateway for display in the Delivery Shield dashboard

• Never exposes credentials outside the cluster — tokens and secrets stay in Kubernetes Secrets, visible only to the agent

How Delegates Work in OpsMx Delivery Shield

The delegate operates through a clean separation between the gateway (control plane) and the agent (execution plane):

OpsMx Gateway (Dashboard / Control Plane)
              ↓  gRPC
         Delegate (SSD Shield Agent — in your cluster)
              ├── Controller   → Manages gateway comms, job lifecycle
              ├── Collector    → Handles webhooks, event processing
              └── Scanner Pods → Execute Trivy / Grype / Semgrep scans
                    ↓
         Results returned to Gateway → Displayed in Reports page

The agent stores all scan configurations as ScanConfig CRDs and executes scans as ScanJob CRDs within the Kubernetes cluster — making the entire scanning infrastructure native, persistent, and manageable via standard Kubernetes tooling.

Key Components of the Delegate

Component	Role
Controller	Manages gateway communication, scan job lifecycle, CRD management, and schedule coordination
Collector	Handles inbound webhook events, processes pipeline triggers, and routes scan requests
Scanner Pods	Spin up on demand to execute scans using Trivy, Grype, and Semgrep — one pod per scan job
ScanConfig CRD	Stores scan configuration — what to scan, which scanners to use, and schedule settings
ScanJob CRD	Represents each individual scan execution — created per trigger, tracks progress and outcome

Benefits for the User

1. Scan Without Webhooks or Pipeline Changes

On-Demand Scanning removes the dependency on webhook configuration or pipeline modifications — any repository or registry can be scanned from the dashboard immediately, without touching the source system.

2. Credentials Never Leave Your Cluster

All authentication tokens and secrets remain in Kubernetes Secrets within your own cluster. The gateway receives only scan results — not credentials — ensuring zero credential exposure across network boundaries.

3. Resilient Scheduling — Gateway-Independent

Scheduled scans run entirely on the agent side — they continue executing even if the gateway is temporarily unavailable, ensuring your security baseline is never interrupted by control plane issues.

4. Flexible Trigger Options for Every Environment

Whether your team uses webhooks, polling, scheduled scans, or manual triggers — Delivery Shield supports all patterns, making it compatible with any repository type, network topology, or team workflow.

5. GitOps-Native CRD Architecture

ScanConfig and ScanJob resources are native Kubernetes CRDs — they can be version-controlled in Git, applied via kubectl, and managed alongside your existing Kubernetes infrastructure with no additional tooling.

6. Unified Scan Results in One Dashboard

Regardless of how a scan was triggered — manual, scheduled, polling, or webhook — all results flow to the same Reports page in Delivery Shield, giving teams a single, consistent view of security findings across all scan targets.