# Excititor Provider Control Plane

This document describes the operator-facing control plane for Excititor VEX providers.

## Operator entry points

- Web UI: `Ops -> Integrations -> Advisory & VEX Sources -> VEX Providers`
- CLI:
  - `stella excititor list-providers`
  - `stella excititor show-provider --provider <id>`
  - `stella excititor enable-provider --provider <id>`
  - `stella excititor disable-provider --provider <id>`
  - `stella excititor run-provider --provider <id> [--since ... --window ... --force]`
  - `stella excititor update-provider --provider <id> ...`

Backend API:

- `GET /excititor/providers`
- `GET /excititor/providers/{providerId}`
- `PUT /excititor/providers/{providerId}`
- `POST /excititor/providers/{providerId}/enable`
- `POST /excititor/providers/{providerId}/disable`
- `POST /excititor/providers/{providerId}/run`

## Readiness states

Excititor providers use four runtime readiness states:

- `ready`: persisted-enabled and the current host has a runnable connector
- `blocked`: persisted-enabled but currently cooling down or otherwise not runnable
- `disabled`: persisted-disabled
- `planned`: cataloged provider without a runnable connector registered on the current host

`enabled` remains the operator intent flag. A provider can be `enabled=true` and still show `planned` or `blocked`.

## Provider inventory

| Provider ID | Kind | Default enabled | Registered in WebService | UI control plane | CLI control plane | Credential / config status | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| `excititor:redhat` | distro | true | yes | yes | yes | Public defaults; metadata and trust overrides can be persisted through the provider control plane. | Registered by default in `StellaOps.Excititor.WebService`. |
| `excititor:ubuntu` | distro | true | yes | yes | yes | Public defaults; metadata and trust overrides can be persisted through the provider control plane. | Registered by default in `StellaOps.Excititor.WebService`. |
| `excititor:oracle` | vendor | true | yes | yes | yes | Public defaults; metadata and trust overrides can be persisted through the provider control plane. | Registered by default in `StellaOps.Excititor.WebService`. |
| `excititor:cisco` | vendor | true | yes | yes | yes | Public CSAF metadata works without a persisted secret path. Optional API token support exists in connector host options, not in the new persisted UI or CLI surface. | Registered by default in `StellaOps.Excititor.WebService`. |
| `excititor:suse-rancher` | hub | false | yes | yes | yes | Discovery and trust metadata can be persisted. Authenticated discovery credentials remain host-config only today. Anonymous discovery can still be allowed by connector options. | Registered by default in `StellaOps.Excititor.WebService`. |
| `excititor:oci-openvex` | attestation | false | yes | yes | yes | Provider metadata and trust overrides can be persisted. Image subscriptions, registry credentials, and cosign credential material remain host-config only today. | Registered by default in `StellaOps.Excititor.WebService`. |
| `excititor:msrc` | vendor | false | conditional | yes | yes | Persisted provider metadata exists, but MSRC connector credentials and offline token settings remain host-config only today. | Registered only when `Excititor:Connectors:Msrc` exists in host configuration. Otherwise the provider remains `planned`. |

## What the current provider control plane persists

The current `update-provider` surface persists:

- display name
- provider kind
- base URIs
- well-known metadata URI
- ROLIE service URI
- trust weight
- PGP fingerprints
- cosign issuer
- cosign identity pattern
- enabled / disabled intent

The current provider control plane does not yet persist connector-secret fields such as:

- MSRC tenant, client ID, client secret, static access token, or offline token path
- Rancher Hub token endpoint, client ID, or client secret
- OCI registry username, password, identity token, refresh token, cosign key pair, or image subscription list
- Cisco optional VEX API token

Those settings still come from host configuration today. The control plane is truthful about the gap by surfacing `planned` or `blocked` readiness instead of pretending the connector is runnable.

## Host wiring notes

- `StellaOps.Excititor.WebService` always registers:
  - Red Hat CSAF
  - Ubuntu CSAF
  - Oracle CSAF
  - Cisco CSAF
  - SUSE Rancher VEX Hub
  - OCI OpenVEX attestations
- `StellaOps.Excititor.WebService` registers Microsoft MSRC CSAF only when the `Excititor:Connectors:Msrc` configuration section exists.
- `StellaOps.Excititor.Worker` seeds these public defaults when no explicit provider schedule list is supplied:
  - `excititor:redhat`
  - `excititor:ubuntu`
  - `excititor:oracle`
  - `excititor:cisco`

## Verification state

Reverified in Sprint `20260422_004`:

- targeted backend tests for provider management endpoints passed against `StellaOps.Excititor.WebService.Tests.ProviderManagementEndpointsTests`
- Angular route helper spec passed for the new VEX provider route
- Angular development build passed with the new provider catalog page
- CLI provider inspection and control verbs were added for the backend surface

The verification above covers the provider control plane and readiness behavior. It does not claim a fresh live ingest verification run for every upstream VEX provider in this sprint.