# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opsmx.com/remediation-agents/kubernetes-agent-delegate.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.